Last post Jan 22, 2014 03:43 AM by Florian Winter
Dec 16, 2013 07:37 AM|Florian Winter|LINK
We are using Global.asax for URL rewriting in our application and noticed that there are some problems with handling encoded number signs ("%23").
If the client sends a request using the URL http://example.org/file%23.txt, then
- Request.RawUrl == "/file#.txt"
- Request.Url.Fragment == "#.txt"
- Request.Url.AbsolutePath == "/file"
As long as Global.asax does not touch the request, then IIS delivers the static file called "file#.txt". However, for rewriting URLs containing "%23", the information in Request.RawUrl and Request.Url is obiously wrong.
Is this a bug or some strange security feature that can be turned off? Is there a way to get hold of the original, unmodified URL?
I originally posted this on the IIS forums. You may find more information here: http://forums.iis.net/t/1206863.aspx?Encoded+number+sign+23+in+URL+path+is+interpreted+as+fragment
Dec 23, 2013 04:20 AM|Pengzhen Song - MSFT|LINK
If the name of txt file is file%23.txt instead of file#.txt in the physical folder, you can try creating a url rewrite rule to redirect url to file%23.txt:
<match url="(file#)\.aspx" />
<action type="Redirect" url="file%23.aspx" />
And configure web.config like this:
<?xml version="1.0" encoding="UTF-8"?>
<defaultDocument enabled="false" />
<directoryBrowse enabled="true" />
<httpRuntime requestPathInvalidCharacters="" requestValidationMode="2.0" />
<pages validateRequest="false" />
Hope it can help you.
Jan 22, 2014 03:43 AM|Florian Winter|LINK
Sorry for the late reply and thanks for your help so far.
There isn't really a physical file. Or rather: There is one, and it is called "file#.txt", and the URL "...file%23.txt" refers to it, but it is not intended to be served as a physical file by IIS. We only did this for testing to verify that .NET and not
IIS decodes the number sign and interprets it as fragment.
This is what we really do: We use Global.asax for rewriting the URL and then have an ISAPI extension written in C++ handle the request. The ISAPI extension should see the URL "/path/to/file%23.txt" with the path part "/path/to/file#.txt" in unescaped form.
If I understand you correctly, then using <rewrite> instead of code in Global.asax for URL rewriting will work around the issue of the "#" sign being decoded prematurely and treated as a fragment. It also seems to me like a good idea in general to use the
URL rewriting module rather than a script for this purpose.
Just out of curiosity: Is this a bug in .NET or intended behavior, and is there a way to work around it in .NET?