http://bugzilla.novell.com/show_bug.cgi?id=620411
http://bugzilla.novell.com/show_bug.cgi?id=620411#c9 --- Comment #9 from Stefan Winkler <[email protected]> 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. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
