IIS enables us to also configure Asp.Net file mappings. Thus besides aspx, IIS also invokes Asp.Net runtime, when requests have the following file extensions:
a) .ascx --> .asmx extension is used to request user controls.
Since user controls can’t be accessed directly, how and why would anyone send a request to a user control?
b) .ashx --> this extension is used for HTTP handlers.
• But why would you want to request an .ashx page directly instead of registering this handler inside configuration file and enable it to be called when files with certain ( non ashx ) extensions are requested?
• Besides, since there can be several Http handlers registered, how will Asp.Net know which handler to invoke if they all use ashx extension?
• What does the requested ashx file contain? Perhaps a definition of a Http handler class?
• I know how we register Http handlers to be invoked when non-ashx pages are requested, but how do we register Http handler for ashx page?
c) .asax --> This extension is used to request a global application file
• Why would we ever want to call Global.asax directly?
• I assume that when request is made for Global.asax, an object derived from HTtpApplication class is created, except this time no web page processing takes place?
thanx
Q - Besides Asp.Net being able to request global.asax for compilation, is there any other reason why I would choose to request file with .asax extension directly?
• ashx files don't have to be registered. They are basically a simpler aspx, for when you don't need the entire page life cycle. A common use is for retrieving dynamic images from a database.
So if I write a Http handler, I should put it in a file with .ashx extension and Asp.Net will build an HttpHandler object similarly to how it builds a page instance from .aspx file?
• If a hacker did try to make a request for one of these files, what would you want to happen? You certainly wouldn't want IIS to treat it like a text file and send the source for your app down to the browser.
Asp.Net could do the same it does with .cs, .csproj, .config, .resx, .licx, .webinfo file types. Namely, it registers these file types with IIS so that it can explicitly prevent users from accessing these files
•Just because you don't expect requests from the browser for a resource, it doesn't mean you don't want that resource handled by the asp.net engine. These extensions are also how ASP.Net picks up files to compile for the web site model sites.
But then why doesn’t Asp.Net also allow .cs, .csproj, .config, .resx, .licx, .webinfo files to be directly requested?
a) and c) - as far as I am aware, these are not exposed to process any external requests
my book claims the two are mapped in IIS
I appreciate your help
EDIT:
b) The .ashx extention is defined in a config file it's just not the web.config, its in the machine.config
<add path="*.ashx" verb="*" type="System.Web.UI.SimpleHandlerFactory" validate="True" />
http://msdn.microsoft.com/en-us/library/bya7fh0a.aspx
Why use .ashx: The difference is that the .NET class that handles a .ashx reads the Page directive in the .ashx file to map the request to a class specified in that directive. This saves you from having to put an explicit path in the web.config for every handler that you have, which could result in a very long web.config.
I thought Http handler class was defined inside .ashx file, but instead file with .ashx extension only contains Page directive?
Since I’m not 100% sure if I understand this correctly: Say we have ten Http handlers we want to invoke by making a request to IIS7. I assume for each Http handler there will be specific .ashx file --> thus if request is made for FirstHandler.asxh, then handler specified inside that file will be invoked?
YET ANOTHER EDIT:
I must confess that I’m still a bit unsure about ashx extension.
I realize that by using it we can for example create 'hey.ashx' page, where Page directive will tell which class ( Http handler) to invoke when request is made for 'hey.ashx' – thus no need to register Http handler in web.config.
But if you use Http handlers that way, then they will only get invoked when requests are made for files with .ashx extension. Thus, if I want Http handler to be invoked for files with other extensions, such as .sourceC, then I will still need to register Http handler in web.config?!
A few points:
asmx files are not the same as ascx files. You use them for web services (soap) rather than web controls.
ashx files don't have to be registered. They are basically a simpler aspx, for when you don't need the entire page life cycle. A common use is for retrieving dynamic images from a database.
If a hacker did try to make a request for one of these files, what would you want to happen? You certainly wouldn't want IIS to treat it like a text file and send the source for your app down to the browser.
Just because you don't expect requests from the browser for a resource, it doesn't mean you don't want that resource handled by the asp.net engine. These extensions are also how ASP.Net picks up files to compile for the web site model sites.
a) and c) - as far as I am aware, these are not exposed to process any external requests
b) by default, it will look for a .ashx file with the path/name requested. This makes it really easy to add a handler to a web site, with no configuration necessary.
Update: In a you also mentioned asmx. My take is the book is explaining some ajax related feature, with some comments regarding:
Asp.net doesn't allow making requests pointed to .ascx.
You can make a request to a web service (.asmx) to get you the info.
There are some built in features to help you with the above.
To definitely clear any confusion you might have on what asp.net does with these requests, check the web.config in:
%systemroot%\Microsoft.NET\Framework\v2.0.50727\CONFIG
As you can see (posted mine below), asp.net excludes pretty much any of the files that you are unsure if they were receiving special treatment. Notice there is *.cs, *.acsx, *.asax.
<add path="*.asax" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.ascx" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.master" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.skin" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.browser" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.sitemap" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.dll.config" verb="GET,HEAD" type="System.Web.StaticFileHandler" validate="True"/>
<add path="*.exe.config" verb="GET,HEAD" type="System.Web.StaticFileHandler" validate="True"/>
<add path="*.config" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.cs" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.csproj" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.vb" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.vbproj" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.webinfo" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.licx" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.resx" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.resources" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.mdb" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.vjsproj" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.java" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.jsl" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.ldb" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.ad" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.dd" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.ldd" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.sd" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.cd" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.adprototype" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.lddprototype" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.sdm" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.sdmDocument" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.mdf" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.ldf" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.exclude" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
<add path="*.refresh" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
Also, bear in mind that IIS might not be configured to map some requests (MIME types) to the ASP.NET pipeline.
a) .ascx can't be accessed directly becasue the default handler is the class System.Web.HttpForbiddenHandler
<add path="*.ascx" verb="*" type="System.Web.HttpForbiddenHandler" validate="True" />
.asmx files can be called directly, they are webmethods (though you usually have to make POST request, unless you specify to allow GET's in the web.config
b) The .ashx extention is defined in a config file it's just not the web.config, its in the machine.config
<add path="*.ashx" verb="*" type="System.Web.UI.SimpleHandlerFactory" validate="True" />
http://msdn.microsoft.com/en-us/library/bya7fh0a.aspx
Why use .ashx: The difference is that the .NET class that handles a .ashx reads the Page directive in the .ashx file to map the request to a class specified in that directive. This saves you from having to put an explicit path in the web.config for every handler that you have, which could result in a very long web.config.
--
c) Global.asax: i don't use gloabl.asax, i rather use the very elegant HttpModule solution, but it's probably setup for legacy sites that had global.asax files.
Related
I'm trying wire up a custom IHttpHandler to process request to my website for *.js files. For the life of me I can't get my httphandler to even be created by IISExpress when a request is made for a js file to my web server. I've tried several variations of the system.webServer handlers setting including.
<add name="MyHandler"
type="BusinessLayer.Web_Stuff.MyHandler, BusinessLayer"
verb="*"
path="*.js"
resourceType="Unspecified"
preCondition="integratedMode"
modules="IsapiModule"
scriptProcessor="c:\windows\Microsoft.net\framework\v4.0.30319\aspnet_isapi.dll"/>
and
<add name="JSHandler"
type="BusinessLayer.Web_Stuff.MyHandler, BusinessLayer"
verb="GET,POST" path="*.js"
resourceType="Unspecified"
preCondition="integratedMode" />
I am running this in Visual Studio 2013 using IISExpress. If i change the path to *.test instead of js then this handler works without any problems, but i cant make it work for *.js files. It seems like IISExpress is handling those requests itself by just serving the files off of disk. Does anyone know how to bypass that so i can make my handler process requests for js files.
Correction: When i use the top web.config setting with IsapiModule specified, an instance of MyHandler is instantiated however the ProcessRequest(HttpContext context) method of the interface is never called on my object. With the bottom definition, no instances of my handler are ever instantiated.
After fighting with this for several hours i finally found the answer. The key was I had to add an attribute to the modules xml element in system.webServer
<modules runAllManagedModulesForAllRequests="true" >
Without this attribute, the process request handler was not being called. After setting that, this is all that was need in the handlers section.
<add name="JSHandler"
type="BusinessLayer.Web_Stuff.ScriptMinifyHandler, BusinessLayer"
verb="*"
path="*.js"
resourceType="Unspecified"
preCondition="integratedMode" />
I will have to read a bit more about this setting, but if anyone can tell me more about why that works I'd love to hear it.
I have a web application running in .net framework 2.0 and hosted on IIS 7.5. The app pool is running in classic mode. I want to intercept all the requests containing .txt files. Below is my entry in web.config
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
<handlers>
<add name="NES.HiLo.Security.CommunityResource, NES.HiLo.Security" verb="*" path="*.txt" type="NES.HiLo.Security.CommunityResource, NES.HiLo.Security" />
</handlers>
</system.webServer>
<httpHandlers>
<add verb="*" path="*.txt" type="NES.HiLo.Security.CommunityResource, NES.HiLo.Security" />
</httpHandlers>
When I m making requests for URL like
http://local.mysite.com/media/CLT/ResourceUploads/1000277/Test1.txt
the handler never kicks in, the control never comes inside the code in the handler.
Any ideas what I m missing? thanks
According to the MSDN example of registering handler in IIS 7.0 in classic mode, you are missing a couple of attributes:
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
<handlers>
<add name="CommunityResourceHandler" verb="*" path="*.txt"
type="NES.HiLo.Security.CommunityResource, NES.HiLo.Security"
modules="IsapiModule"
scriptProcessor="FrameworkPath\aspnet_isapi.dll"
resourceType="File" />
</handlers>
</system.webServer>
<httpHandlers>
<add verb="*" path="*.txt" type="NES.HiLo.Security.CommunityResource, NES.HiLo.Security" />
</httpHandlers>
I am facing an error on the tree view control. Image is shown below.
What could be the potential reasons for it. I have transferred published code from one PC to another. The target machine is having windows 2008 server.
Everything is fine except the treeview control:
What could be the potential reasons for it?
Update
Here is an excerpt from my web.config
<system.webServer>
<validation ntegratedModeConfiguration="false" />
<handlers>
<add name="ReportViewerWebControl"
path="Reserved.ReportViewerWebControl.axd" verb=""
type="Microsoft.Reporting.WebForms.HttpHandler"
resourceType="Unspecified"
requireAccess="Script"
preCondition="integratedMode" />
<add name="ReportViewerWebControlHandler"
preCondition="integratedMode"
verb=""
path="Reserved.ReportViewerWebControl.axd"
type="Microsoft.Reporting.WebForms.HttpHandler, Microsoft.ReportViewer.WebForms, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</handlers>
This happens when you transfer files from one server to another but miss out the mapping for axd files.
Many controls embed images inside dlls and retrive them using WebResource.axd.
A common cause is moving from one version of IIS to another.
In IIS6 you would map it as:
<httpHandlers>
<add verb=”Get” path=”WebResource.axd”
type=”System.Web.Handlers.AssemblyResourceLoader” />
</httpHandlers>
However in IIS7 you will need
<system.webServer>
<modules>
</modules>
<handlers>
<add name=”webresources” verb=”Get” path=”WebResource.axd”
type=”System.
Web.Handlers.AssemblyResourceLoader” />
</handlers>
</system.webServer>
What kind of purpose do .axd files serve?
I know that it is used in the ASP.Net AJAX Toolkit and its controls. I'd like to know more about it.
I tried Googling for it, but could not find getting basic information.
from Google
An .axd file is a HTTP Handler file. There are two types of .axd files.
ScriptResource.axd
WebResource.axd
These are files which are generated at runtime whenever you use ScriptManager in your Web app. This is being generated only once when you deploy it on the server.
Simply put the ScriptResource.AXD contains all of the clientside javascript routines for Ajax. Just because you include a scriptmanager that loads a script file it will never appear as a ScriptResource.AXD - instead it will be merely passed as the .js file you send if you reference a external script file. If you embed it in code then it may merely appear as part of the html as a tag and code but depending if you code according to how the ToolKit handles it - may or may not appear as as a ScriptResource.axd. ScriptResource.axd is only introduced with AJAX and you will never see it elsewhere
And ofcourse it is necessary
Those are not files (they don't exist on disk) - they are just names under which some HTTP handlers are registered.
Take a look at the web.config in .NET Framework's directory (e.g. C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\web.config):
<configuration>
<system.web>
<httpHandlers>
<add path="eurl.axd" verb="*" type="System.Web.HttpNotFoundHandler" validate="True" />
<add path="trace.axd" verb="*" type="System.Web.Handlers.TraceHandler" validate="True" />
<add path="WebResource.axd" verb="GET" type="System.Web.Handlers.AssemblyResourceLoader" validate="True" />
<add verb="*" path="*_AppService.axd" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" validate="False" />
<add verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" validate="False"/>
<add path="*.axd" verb="*" type="System.Web.HttpNotFoundHandler" validate="True" />
</httpHandlers>
</system.web>
<configuration>
You can register your own handlers with a whatever.axd name in your application's web.config. While you can bind your handlers to whatever names you like, .axd has the upside of working on IIS6 out of the box by default (IIS6 passes requests for *.axd to the ASP.NET runtime by default). Using an arbitrary path for the handler, like Document.pdf (or really anything except ASP.NET-specific extensions), requires more configuration work. In IIS7 in integrated pipeline mode this is no longer a problem, as all requests are processed by the ASP.NET stack.
An AXD file is a file used by ASP.NET applications for handling embedded resource requests. It contains instructions for retrieving embedded resources, such as images, JavaScript (.JS) files, and.CSS files. AXD files are used for injecting resources into the client-side webpage and access them on the server in a standard way.
I am developing an ASP.NET MVC applications with MS Visual Studio 2008 SP1.
My project structure is the default one:
Project |-Content |-css |-img |-Models |-Views
|-Controllers
The thing is, I am able to access all the content placed under Content directory provided the file is included in the project. On the other hand, if I happen to have an image (I.E. an image uploaded by the user) that's on the right physical directory (Project\Content\img) but is not included in the project, I keep getting a 404 error when I access them with a browser.
I think my URL is correct:
http://localhost:1260/Content/img/my_image.jpg
And I do have a file under Project\Content\img\my_image.jpg.
What can be wrong? Am I forced to include all the files on the project? I don't think so, because that would mean that I can't have images uploaded and saved by the web users this way.
Thanks a lot.
If you're hosting your project with IIS 7, you must add he content-type in IIS 7(Handler Mapping). But if you're hosting your project with the Asp.net Developer Server, it's not required.
Using the following code in web.config file
<configuration>
<system.webServer>
<handlers>
<add name="css mapping" path="*.css" verb="*" type="System.Web.StaticFileHandler" resourceType="Unspecified" preCondition="integratedMode" />
<add name="js mapping" path="*.js" verb="*" type="System.Web.StaticFileHandler" resourceType="Unspecified" preCondition="integratedMode" />
<add name="gif mapping" path="*.gif" verb="*" type="System.Web.StaticFileHandler" resourceType="Unspecified" preCondition="integratedMode" />
<add name="jpg mapping" path="*.jpg" verb="*" type="System.Web.StaticFileHandler" resourceType="Unspecified" preCondition="integratedMode" />
<add name="png mapping" path="*.png" verb="*" type="System.Web.StaticFileHandler" resourceType="Unspecified" preCondition="integratedMode" />
</handlers>
</system.webServer>
</configuration>