Go to this link.
I guess I should have just entered this as a bug.
By default, the ASP.NET runtime doesn't even attempt to serve certain requests that look like they might be accessing a protected file.
You'll also notice that the following will fail as well.
This can be turned off in web.config or IIS7.
The "fix" for this is kind of nuclear, as it would allow access to raw sourcecode and configuration data for the actual website itself.
Thus, I have elected to globally rename these tags to
In the future, when the tag blacklist / forced-synonyms is implemented, the dot equivalents will be blacklisted/auto-replaced.
As a workaround, you can search for "global asax" (just replace the dot with a space).
Apparently SO is hosted on IIS. In my opinion, there are two issues here and I wonder why it was tagged "status-declined" as they are both trivial to fix:
Please reopen this. If you need help implementing a fix or need more elaboration on the workarounds, the ups and downs of it etc, you can always contact me off-site.
I would think that it is because when you search for global.asax you end up putting .asax in the url as though it were a page! Which causes the .net engine to vomit!
It only works on global.asax, not foo.asax
The .asax causes the browser to treat it as a file, which when the request is sent to the server, returns a 404 error. I am in google chrome, and yes, I see the error.
Stackoverflow administrators: Perhaps edit .htaccess to include a rewrite for the 404 page to make this and other glitchy tags redirect to their proper pages?
This is the only glitch like it I have seen so far.