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.

| improve this answer | |

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

  • web-config
  • global-asax

In the future, when the tag blacklist / forced-synonyms is implemented, the dot equivalents will be blacklisted/auto-replaced.

| improve this answer | |

As a workaround, you can search for "global asax" (just replace the dot with a space).

| improve this answer | |

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:

  1. The error page is a default error page and should show a human readable error page. Showing the parser error is almost as bad as showing a stacktrace. While this isn't fixed, just change the default error page to a "oops, something went wrong, please report or try again" page.
  2. Fixing this is trivial: add a rewrite rule in IIS to replace the dot in global.asax (or any dot-containing expression) with an underscore or similar. In the database, the reverse must be done: underscores must be replaced by dots, of course. This has two wins: firstly, it immediately allows for "illegal" strings and secondly, it enhances security by not telling possible hackers how you've configured your environment.

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.

| improve this answer | |
  • we do use a custom error page, unfortunately that particular code path in the ASP.NET engine bypasses it. Shrug. – Jeff Atwood Oct 25 '09 at 20:44
  • as for the rewrites, we'd have to have one rewrite for every single problematic tag. Because we do allow tags with dots in them, it's just certain tags with dots are disallowed by the ASP.NET engine. – Jeff Atwood Oct 25 '09 at 20:59
  • the workaround would indeed only work or be useful if you could apply it throughout. Still, depending on how important it is to correct this behavior, applying it to all and use a bit of logic for the back/forth transition shouldn't be awfully hard and has the benefit of creating a better future-proof system that allows any character (if needed) in the path. – Abel Oct 26 '09 at 2:15

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!


| improve this answer | |

It only works on global.asax, not foo.asax

| improve this answer | |

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.

| improve this answer | |

You must log in to answer this question.