IIS is encoding characters in a redirect, to prevent cross site scripting. I cannot tell why IIS encodes the underscore character (or the hyphen character for that matter), because i cannot see any issues with that. I can assume that the developers of IIS was looking at RFC 1738, which says (section 2.2):
"On the other hand, characters that are not required to be encoded (including alphanumerics) may be encoded within the scheme-specific part of a URL, as long as they are not being used for a reserved purpose."
The developers are following this, and maybe they wanted to be on the secure side, and encode the character.
I do not know what problems with cookies or paths you are referencing to, but cookies are for sure not handled by IIS. Paths, maybe, depends on what it is.
_ and %5F should be treated equally. IIS handles this, but for cookies, it can be a problem with the client (the webbrowser), or ASP/something else, depending on the problem, and if you are using ASP or some other scripting technique.
In RFC 3986 (which updates RFC 1738, but was released 2005, so the IIS developers could impossible follow it when developing IIS) the underscore character should not be encoded.
I discussed this "problem" with Olaf Lüder, another MVP, and he wrote an ISAPI filter to work-around this. If it fixes the cookies problem as well, i have no idea. This is available here:
If you find this to be major problem, and nobody else responds with a better explanation, you could contact Microsoft Support. It does however not seem to be a bug in IIS, because the behavior seems to be intentional.
It's called an encoded underscore. No web server does it. IE does it. Really, do you think that IIS would produce such "stupid" behavior?
John Cesta
The CPU Checker - Monitors your CPU % while you sleep LogFileManager - IIS LogFile Management Tool WebPageChecker - Helps Maintain Server UpTime DomainReportIt PRO - Helps Rebuild IIS http://www.serverautomationtools.com
As Kristopher pointed out, the reason for the encoding is for security against cross-site scripting attacks. Despite the fact that XSS attacks are fundamentally a client-side problem due to bad application code on the server, people wanted a server-side heavy-hammer solution, and here it is.
Regarding your problems with cookies, paths, etc -- it simply points out that your code contains potential canonicalization flaws in that it treats the same URL as potentially different. Basically, it is the reverse of the XSS attack but from the server to the client.
David Wang [Msft] wrote: > As Kristopher pointed out, the reason for the encoding is for security > against cross-site scripting attacks. Despite the fact that XSS attacks are > fundamentally a client-side problem due to bad application code on the > server, people wanted a server-side heavy-hammer solution, and here it is.
> Regarding your problems with cookies, paths, etc -- it simply points out > that your code contains potential canonicalization flaws in that it treats > the same URL as potentially different. Basically, it is the reverse of the > XSS attack but from the server to the client.
