[Mono-bugs] [Bug 620411] RewritePath crashes with an unidentified null reference exeption in PostAcquireRequestState
bugzilla_noreply at novell.com
bugzilla_noreply at novell.com
Fri Jul 9 08:39:56 EDT 2010
http://bugzilla.novell.com/show_bug.cgi?id=620411
http://bugzilla.novell.com/show_bug.cgi?id=620411#c9
--- Comment #9 from Stefan Winkler <s.winkler at studdex.com> 2010-07-09 12:39:55 UTC ---
I have some feedback regarding your fix. I applied it to a mono source I
debugged with monodevelop, after porting our solution over. After applying it,
a completely blank page was returned instead of an error page, so our specific
problem wasn't solved by that. But the fix prevented the crash and didn't have
any harmful side effects, so I guess it's safe to commit it to 2.6 anyway, one
can never have enough null-checks.
I did some more research and I guess I found out what happens, though I still
don't know why:
The crash doesn't actually happen upon calling RewritePath in
Application_BeginRequest, but afterwards. The request path can't be processed
by the RewritePath method and therefore leads to an invalid location. Then a
regular request is fired for that invalid path and because nothing is found
there, the type of the file to serve can't be determined and therefore no
Handler is selected, causing the error in PostAquireRequestState, where the
CurrentHandler, like you already mentioned, should actually never be null.
So, what was wrong with the request path?
Well, our rewriting class takes the Request.AppRelativeCurrentExecutionFilePath
as input parameter and if it contains a certain keyword, returns the path to
the real file that needs to be served in the format "~/folders/file.aspx?x=y".
The ~ is needed if we want to put the result into the path parameter for
methods like Server.Transfer, Response.Redirect, or Server.MapPath.
For RewritePath however, we need the relative server path, determined like
this:
application.Request.ApplicationPath + s.Substring(1)
That's because some of our test evironments were using a virtual path and the
files wouldn't be found if that was missing. That also explains why the latest
version didn't fail on our test server, because it used a virtual path. And if
the virtual path is, for example "/vpath", the input string looks like
"/vpath/folders/file.aspx?x=y" and everything works fine. But if the virtual
path points to the root directory ("/"), then the input string will look like
this:
"//folders/file.aspx?x=y".
Double slash at the beginning. Ouch. Windows ignores this (maybe by
automatically replacing each double slash with a single one) and for some
reason, mono apparently did the same in the past (this part of the code is
actually quite old). But for some mysterious reason, modyfing or deleting one
of 3 certain files in our web application's root folder (all of those were
files that used runat-server script blocks instead of codebehind) changed the
bahaviour of that auto-fix or whatever is going on behind the scenes and now it
fails. If I run a string.Replace("//","/") on the path before submitting it to
RewritePath, everything works fine again.
Of course that doesn't explain at all what exactly happened internally, but at
least it fixes our error, so I'm fine with that and won't look into the matter
any further, I already spent too much time for that and have to catch up with
development now. Good luck to anyone who wants to search for the mysterious
cause of this, though.
--
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
More information about the mono-bugs
mailing list