This is definitely a bug in IIS 6.0 and DotNet Framework 2.0!!

[Jay Balapa]

This am I posted the following message thinking there was a problem with Dot
Net Framework 2.0. But problem occurs only with Dot Net 2.0 and IIS 6.0
installed machines. I tested this on my laptop running 5.1 and Framework 2.0
and runs perfectly fine.

Can anyone from Microsoft help me. I have all our ASP.Net applications
converted 2.0 and Iam left hanging with this bug.
Jay



Hello,

We have a website running ASP.Net 1.1 using forms authentication and even
protects .htm/.doc files. We have associated such files to ASP.Net in
Application Settings.


Everything was working great until we moved to 2.0.

If we try to access a .htm page we get "Page cannot be displayed errror".
In the Application settings there are two check boxes "script engine" and
"verify that file exists" both are checked by default.


If the script engine check box is unchecked then it gives me "execute access
is
denied" error.

Why is this breaking change from 1.1 to 2.0, how do we resolve it?

Thanks.

 

[Ken Schaefer]

For the request in question, what is being logged in the IIS logfile? Please
post the relevant entry/entries.

Thanks

Cheers
Ken


: This am I posted the following message thinking there was a problem with
Dot
: Net Framework 2.0. But problem occurs only with Dot Net 2.0 and IIS 6.0
: installed machines. I tested this on my laptop running 5.1 and Framework
2.0
: and runs perfectly fine.
:
: Can anyone from Microsoft help me. I have all our ASP.Net applications
: converted 2.0 and Iam left hanging with this bug.
: Jay
:
:
:
: Hello,
:
: We have a website running ASP.Net 1.1 using forms authentication and even
: protects .htm/.doc files. We have associated such files to ASP.Net in
: Application Settings.
:
:
: Everything was working great until we moved to 2.0.
:
: If we try to access a .htm page we get "Page cannot be displayed errror".
: In the Application settings there are two check boxes "script engine" and
: "verify that file exists" both are checked by default.
:
:
: If the script engine check box is unchecked then it gives me "execute
access
: is
: denied" error.
:
: Why is this breaking change from 1.1 to 2.0, how do we resolve it?
:
: Thanks.
:
: --
: Jay Balapa
: www.atginc.com
:
:
:
:

 

[David Wang [Msft]]

Please first read this blog entry on troubleshooting.

http://blogs.msdn.com/david.wang/archive/2005/12/31/HOWTO_Basics_of_IIS6_Troubleshooting.aspx

Realize that making random configuration changes prior to careful analysis
of the original error condition, as mentioned by the blog entry, does not
help your situation.

In your case, unchecking "Script Engine" does not help because it is the
means by which resources with Application Mappings can be executed when
Execute Permission is merely "Script" (which is the default setting). Don't
fiddle around with it nor the Execute Permission because... oh, just read
the blog entry for why.


So, please provide the log entry corresponding to the request which is
supposed to succeed but is not.

Now, since you are using non-standard configuration, also provide any
non-default Application mapping modifications as well as
web.config/machine.config modifications to make your current application
work.

In particular, are you seeing the failure on all content types mapped to
aspnet_isapi.dll or just .htm/.doc.

Since mapping non dot-net content to aspnet_isapi.dll to be protected by
Forms Authentication is not exactly the normal/default scenario, some things
actually did change on upgrade... But we need to first confirm your custom
configuration.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//

 

[Jay Balapa]

Ken and David,

Thanks for replying to my post.


***************************************888

So, please provide the log entry corresponding to the request which is
supposed to succeed but is not.

**********************************************88
Here are the log file entries- First entry is the aspx entry second is the
..htm entry not working.

2006-01-11 15:17:02 W3SVC1 10.0.0.32 POST /login.aspx - 80 - 10.0.0.163
Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1;+.NET+CLR+1.1.4322;+.NET+CLR+1.0.3705;+.NET+CLR+2.0.50727)
302 0 0
2006-01-11 15:17:02 W3SVC1 10.0.0.32 GET /clients/vipdemo/gateway.htm - 80 -
10.0.0.163
Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1;+.NET+CLR+1.1.4322;+.NET+CLR+1.0.3705;+.NET+CLR+2.0.50727)
200 0 0




********************************************

web.config/machine.config modifications to make your current application
work.

***********************************************8

We just followed the default forms authentication guidelines, following are
the entries-
In the root folder this was the entry-
<system.web>
<sessionState mode="InProc" cookieless="true" />
<trace enabled="true" requestLimit="10" pageOutput="true"
traceMode="SortByTime" localOnly="true"/>
<authentication mode="Forms">
<forms loginUrl="login.aspx" protection="All" />
</authentication>
<customErrors mode="Off"/>
</system.web>

In the sub folder where we need protection we have this at the root-

<system.web>
<authorization>
<deny users="?"></deny>
</authorization>
</system.web>


******************************************************888

In particular, are you seeing the failure on all content types mapped to
aspnet_isapi.dll or just .htm/.doc.

************************************************************
Iam only seeing failure on mapped files like .htm/.doc. There are no issues
with aspx files. If I take the mapping off everything works great, but
files are not protected.

Thanks again for all your help.

jay Balapa
www.atginc.com

 

[David Wang [Msft]]

The log entry says that IIS handed the request to ASP.Net, so there is no
bug in IIS6 portion. I do not think there is a bug in the ASP.Net portion,
either, because I've used ASP.Net 2.0 to protect non-.Net content before
with no problems.

Is there anything in your .config file which prevents .htm or .doc from
being served by ASP.Net. In particular, what does your upgraded
machine.config look like for the httpHandler section -- is it actually
configured to serve the resources you are talking about.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//

 

[zzhumphreyt]

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?

 

[Christopher Reed]

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.

 

[zzhumphreyt]

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\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>

 

[David Wang [Msft]]

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.
//