IIS HTTP Error 400

Here is a little something that came up last week. It came about as we were trying to parse some Wikipedia-style links in a new way for Skweezer. The problem we were facing was that while many links inside of a Wikipedia page are okay, all of the links with colons were failing. The wiki software uses the colon character liberally, such as this: http://en.wikipedia.org/wiki/Wikipedia:Contents

It turns out that IIS does not like the colon character (“:”) in a URL. If you request an asset with the colon character embedded and the page is served by IIS, you may receive an error: “HTTP 400 Bad Request”. Colons are acceptable in one part of the URL: the host name, where they indicate a non-standard port like this: http://barnabas.wordpress.com:8080/. However, if a colon appears anywhere else in the URL, IIS will complain with HTTP error 400. Objectively this is good; IIS is defending itself against what it perceives as a hack attack. I do not know for sure, but I imagine that this particular colon check is defending against an old exploit from 1998.

But wait: can’t you encode the offending colon using standard encoding techniques? That would result in a link that would look more like this (which works): http://en.wikipedia.org/wiki/Wikipedia%3AContents. As it turns out, ASP.NET doesn’t like that either and Microsoft already knows about it and describes a resolution in the “Knowledge” Base. In addition to the evil colon, I particularly enjoy this note: “You may also receive this error message if the URL contains the following characters: * % &”. The recommended resolution is to install a patch and modify the registry. Unfortunately that makes the “fix” not recommended for us. A design goal of our software is to have it up and running on a standard web server installation. Registry hacks break the XCOPY deploy model as far as I’m concerned.

Our current workaround is to use a custom encoding scheme that doesn’t use the percent sign, such as using “_~3A” instead of “%3A”, which strikes me as unnecessary. Our long-term resolution is to look for ways to migrate off IIS.

Comments are closed.