test machine, which has IIS 5.1, I can map htm files to ASP.NET 2.0 and
it works fine but when I move my app to the production server running
IIS 6 and configure the virtual directory to send htm files to ASP.NET
2.0 the files are not served. When I check the log files I see the
request comes in but zero bytes are sent out, no headers, nothing. I'm
not aware of any configuring being done to the server either as we just
installed .NET 2.0 on Monday and I'm the one primarily using it. I
should mention ASP.NET 1.1 on the same server can send htm files
without problem, it's only ASP.NET 2.0 and only on IIS 6 where the
problem occurs. Does anyone have any insight into this?If you have 1.1 on the same W2K3 Server as the 2.0, you have to run the
ASP.NET in separate application pools. In IIS, create a new application
pool and then through the Properties dialog of your web app using 2.0,
change to the new application pool.
--
Christopher A. Reed
"The oxen are slow, but the earth is patient."
<zzhumphreyt@.gmail.com> wrote in message
news:1138804187.904844.308490@.f14g2000cwb.googlegroups.com...
> I'm seeing this same problem with IIS 6 and ASP.NET 2.0 as well. On my
> test machine, which has IIS 5.1, I can map htm files to ASP.NET 2.0 and
> it works fine but when I move my app to the production server running
> IIS 6 and configure the virtual directory to send htm files to ASP.NET
> 2.0 the files are not served. When I check the log files I see the
> request comes in but zero bytes are sent out, no headers, nothing. I'm
> not aware of any configuring being done to the server either as we just
> installed .NET 2.0 on Monday and I'm the one primarily using it. I
> should mention ASP.NET 1.1 on the same server can send htm files
> without problem, it's only ASP.NET 2.0 and only on IIS 6 where the
> problem occurs. Does anyone have any insight into this?
>
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.
//
<zzhumphreyt@.gmail.com> wrote in message
news:1138890016.293264.70150@.g47g2000cwa.googlegroups.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
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\CONFIG\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>
>
0 comments:
Post a Comment