IIS7 file mappings - .asax, .ashx, .asap

2019-05-07 02:01发布

问题:



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?!

回答1:

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.



回答2:

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.


回答3:

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.


回答4:

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.