404 Problems in ASP.NET 2.0

[Joel D. Kraft]

I've been very happy with the performance and new features of my site
since we converted to ASP.NET 2.0 beta 2.

I have noticed a couple of interesting problems, though, which I am
trying to figure out. I can't confirm that they didn't exist under
1.1, but I didn't notice them at that time.

My error handling is configured as follows:
- In IIS, 404 errors are mapped to /site/error/404.aspx.
- "Verify that file exists" is ON for .aspx pages. (So this
really shoudln't be in the picture at all.)
- In web.config, custom errors are OFF
- In global.asax, I have the following code:
if (Context.Error is HttpException)
{
HttpException hex = (HttpException)Context.Error;
if (hex.GetHttpCode() == 404)
Server.Transfer("/site/error/404.aspx");
}
Other errors are just logged to the event log.
- My /site/error/404.aspx sends me email about "interesting" errors
- Other errors are simply logged.

Here are the two problems I am encountering:

First, I have a page, /vision/community.aspx. It exists. It's
there, and it works. The URL to this page was recently sent in
a mass email. When I click on the link in the email, the page
shows up fine, for every person I've asked, the page shows up fine.
BUT almost 100 requests for this page ended up being processed by
my 404 error handler. Is there something else that could cause
a page not to be available? (Some sort of locking issue?!)

I've seen this randomly before with a page here or there and
didn't think anything of it. This, however, is a big problem.

Seconly, I have some pages that really do NOT exist, that
seem to bypass the 404 altogether. I get an exception logged,
and the log shows that the http error code was 404...

System.Web.HttpException: The file '/nofile.aspx' does not exist.
at System.Web.UI.Util.CheckVirtualFileExists(String virtualPath)
at System.Web.Compilation.BuildManager.GetVPathBuildR esultInternal(String
virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean
allowBuildInPrecompile)
at
System.Web.Compilation.BuildManager.GetVPathBuildR esultWithNoAssert(HttpContext
context, String virtualPath, Boolean noBuild, Boolean allowCrossApp,
Boolean allowBuildInPrecompile)
at System.Web.UI.PageHandlerFactory.GetHandler(HttpCo ntext context, String
requestType, String virtualPath, String path)
at System.Web.HttpApplication.MapHttpHandler(HttpCont ext context, String
requestType, String path, String pathTranslated, Boolean useAppConfig)
at
System.Web.HttpApplication.MapHandlerExecutionStep .System.Web.HttpApplication.IExecutionStep.Execute ()
at System.Web.HttpApplication.ExecuteStep(IExecutionS tep step, Boolean&
completedSynchronously)

Any insight is greatly appreciated!
Joel

[Steven Cheng[MSFT]]

Hi Joel,

Welcome to ASPNET newsgroup.
First, I really appreciate your positive feedback on the performance and
other improvement in asp.net 2.0, also I'm sure our dev guys will be very
glad to hear this.
As for the 404 error problem you mentioned, based on my experience, this
behavior would be same in asp.net 1.x and 2.0. Not sure on your detailed
environment, but for 404 error, if the "check file exists" option has been
checked in IIS and the file does not exist, the IIS will report the error
and ASP.NET won't have the chance to capture the error(in Application_Error
event). So you can first isolate the problem into two condition:
1. IIS reported 404 error which can't be handled in asp.net, we can check
them in IIS LOG.
2. ASP.NET reported error ,

Also, as you mentioned that the problem occurs when user click the link
embeded in the email. We can also check the link in the email to see
whether it has any particular problem( for example, it's a relative path
which may cause path problem when in incorrect context).

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)


--------------------
| From: "Joel D. Kraft" <jd******@nospam.nospam>
| Subject: 404 Problems in ASP.NET 2.0
| Date: Thu, 1 Sep 2005 13:03:39 -0400
| Lines: 62
| Organization: Case Western Reserve University
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
| X-RFC2646: Format=Flowed; Original
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
| Message-ID: <Oa**************@TK2MSFTNGP11.phx.gbl>
| Newsgroups: microsoft.public.dotnet.framework.aspnet
| NNTP-Posting-Host: boromir.stuaff.cwru.edu 129.22.161.150
| Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFT NGP11.phx.gbl
| Xref: TK2MSFTNGXA01.phx.gbl
microsoft.public.dotnet.framework.aspnet:121782
| X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet
|
| I've been very happy with the performance and new features of my site
| since we converted to ASP.NET 2.0 beta 2.
|
| I have noticed a couple of interesting problems, though, which I am
| trying to figure out. I can't confirm that they didn't exist under
| 1.1, but I didn't notice them at that time.
|
| My error handling is configured as follows:
| - In IIS, 404 errors are mapped to /site/error/404.aspx.
| - "Verify that file exists" is ON for .aspx pages. (So this
| really shoudln't be in the picture at all.)
| - In web.config, custom errors are OFF
| - In global.asax, I have the following code:
| if (Context.Error is HttpException)
| {
| HttpException hex = (HttpException)Context.Error;
| if (hex.GetHttpCode() == 404)
| Server.Transfer("/site/error/404.aspx");
| }
| Other errors are just logged to the event log.
| - My /site/error/404.aspx sends me email about "interesting" errors
| - Other errors are simply logged.
|
| Here are the two problems I am encountering:
|
| First, I have a page, /vision/community.aspx. It exists. It's
| there, and it works. The URL to this page was recently sent in
| a mass email. When I click on the link in the email, the page
| shows up fine, for every person I've asked, the page shows up fine.
| BUT almost 100 requests for this page ended up being processed by
| my 404 error handler. Is there something else that could cause
| a page not to be available? (Some sort of locking issue?!)
|
| I've seen this randomly before with a page here or there and
| didn't think anything of it. This, however, is a big problem.
|
| Seconly, I have some pages that really do NOT exist, that
| seem to bypass the 404 altogether. I get an exception logged,
| and the log shows that the http error code was 404...
|
| System.Web.HttpException: The file '/nofile.aspx' does not exist.
| at System.Web.UI.Util.CheckVirtualFileExists(String virtualPath)
| at System.Web.Compilation.BuildManager.GetVPathBuildR esultInternal(String
| virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean
| allowBuildInPrecompile)
| at
|
System.Web.Compilation.BuildManager.GetVPathBuildR esultWithNoAssert(HttpCont
ext
| context, String virtualPath, Boolean noBuild, Boolean allowCrossApp,
| Boolean allowBuildInPrecompile)
| at System.Web.UI.PageHandlerFactory.GetHandler(HttpCo ntext context,
String
| requestType, String virtualPath, String path)
| at System.Web.HttpApplication.MapHttpHandler(HttpCont ext context, String
| requestType, String path, String pathTranslated, Boolean useAppConfig)
| at
|
System.Web.HttpApplication.MapHandlerExecutionStep .System.Web.HttpApplicatio
n.IExecutionStep.Execute()
| at System.Web.HttpApplication.ExecuteStep(IExecutionS tep step, Boolean&
| completedSynchronously)
|
| Any insight is greatly appreciated!
| Joel
|
|
|

[Joel D. Kraft]

"Steven Cheng[MSFT]" <st*****@online.microsoft.com> wrote in message
news:iA****************@TK2MSFTNGXA01.phx.gbl...

1. IIS reported 404 error which can't be handled in asp.net, we can check

> them in IIS LOG.

2. ASP.NET reported error ,
Also, as you mentioned that the problem occurs when user click the link
embeded in the email. We can also check the link in the email to see
whether it has any particular problem( for example, it's a relative path
which may cause path problem when in incorrect context).

UGh. I think we sorted it out. I wasn't really paying attention
to the IIS logs because "verify file exists" is OFF in IIS. BUT
for this particular problem, it was smart to check anyway.
Apparently some email clients added the period at the end of the
sentence to the end of the URL... so IIS saw a different exension
which WAS set to verify file exists.

We didn't notice in our notification messages... because we
interpreted the period as the end of the sentence as well. UGH!

Joel