Actually, DefaultHttpHandler has to act differently between IIS5.1 on XP Pro
and IIS6 on WS03 because of new functionality. The new functionality made
some of the old configuration not work (but others work even better), but I
think you'll find the new alternatives more powerful.
What you describe would work if you mapped .* instead of .htm to
ASPNET_ISAPI.DLL. With IIS6 and ASP.Net it is no longer necessary to
pick-and-choose the scriptmapping up-front. DefaultHttpHandler is able to
hand the request *back* to IIS6 for processing. How is this useful?
On ASP.Net 1.1, people liked to map content to ASP.Net to apply forms auth
to them. Unfortunately, ASP.Net 1.1 had no way to hand the request back to
IIS, so this only worked for static content; you could not apply ASP.Net
forms auth to ASP content and still have that page correctly process as ASP.
Thus it is necessary to pick-and-choose the extensions to configure
Application Mappings. Well on ASP.Net and IIS6, you *can* with the
DefaultHttpHandler and it works by default... it you configure
ASPNET_ISAPI.DLL as the wildcard application mapping.
Put another way - now that DefaultHttpHandler is able to hand requests back
to IIS it is now possible to setup infinite loops for request processing.
You found one of them - map .htm to ASPNET_ISAPI.DLL and then make a request
to .htm resource, which is routed to ASPNET_ISAPI.DLL, which has no
HttpHandler for .htm and falls through to DefaultHttpHandler, who hands the
request back to IIS, who routes .htm to ASPNET_ISAPI.DLL... and you have a
loop.
What you did, map .htm to StaticFileHandler , works because it breaks the
loop, but it is not as efficient as mapping .* to ASPNET_ISAPI.DLL, letting
DefaultHttpHandler route that request back to IIS, who has special logic to
break loops for wildcard application mappings... which then allows you to
take advantage of the native Static File Handler.
The entire area of applying ASP.Net HttpModule/HttpHandler to non-ASP.Net
resource and reconciling IIS ScriptMaps and HttpHandler is currently
confusing unless you understand both IIS and ASP.Net architecture (or you
just blindly follow whatever people seem to be doing)... and it is something
we are addressing in a unified approach in IIS7.
--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
<zz*********@gmail.com> wrote in message
news:11*********************@g47g2000cwa.googlegro ups.com...
I did that. I was looking into this more and discovered the default
web.config for htm files in 2.0 is set to the
System.Web.DefaultHttpHandler class. I used WinMerge to compare the
default web.config on the server to the one on my machine and they're
the same. Since this class wasn't working I was looking at other
httpHandlers in the config and saw the System.Web.StaticFileHandler
being used for some files. I added lines in my app's web.config to set
htm files to that and everything started working. I'm glad I'm found a
solution but I'm still confused why I would even need to do this in the
first place since the default config works on my machine but not the
server. I have ASP.NET 1.1 on my machine too, just like the server.
I'm at a loss and still inclined to believe there's a bug or something
screwy between ASP.NET 2.0 and IIS 6, or rather the
System.Web.DefaultHttpHandler class acts differently in this
environment than in others.
But to recap, if this can help others, I added these lines to my own
app's web.config file, I didn't touch the default web.config file here
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONF IG\web.config because
I didn't want to affect other app's on the server.
<httpHandlers>
<add path="*.htm" verb="*" type="System.Web.StaticFileHandler"
validate="True" />
<add path="*.html" verb="*" type="System.Web.StaticFileHandler"
validate="True" />
</httpHandlers>