locked
Encoded number sign ("%23") in URL path is interpreted as fragment RRS feed

  • Question

  • User-845709154 posted

    Hi,

    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

    Monday, December 16, 2013 7:37 AM

Answers

  • User1938476581 posted

    HI,

    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:

    <rewrite>
                <rules>
                    <rule name="Test1">
                        <match url="(file#)\.aspx" />
                        <action type="Redirect" url="file%23.aspx" />
                    </rule>
                </rules>
            </rewrite>

    And configure web.config like this:

    <?xml version="1.0" encoding="UTF-8"?>
    <configuration>
        <system.webServer>
            <defaultDocument enabled="false" />
            <directoryBrowse enabled="true" />
            <rewrite>
                .....
            </rewrite>
           <security>
    		<requestFiltering allowDoubleEscaping="true"></requestFiltering>
    		 
    	</security>
        </system.webServer>
    <system.web>
    	<httpRuntime requestPathInvalidCharacters="" requestValidationMode="2.0" />
        <pages validateRequest="false" />
    </system.web>
    </configuration>


    Hope it can help you.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, December 23, 2013 4:20 AM

All replies

  • User1938476581 posted

    HI,

    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:

    <rewrite>
                <rules>
                    <rule name="Test1">
                        <match url="(file#)\.aspx" />
                        <action type="Redirect" url="file%23.aspx" />
                    </rule>
                </rules>
            </rewrite>

    And configure web.config like this:

    <?xml version="1.0" encoding="UTF-8"?>
    <configuration>
        <system.webServer>
            <defaultDocument enabled="false" />
            <directoryBrowse enabled="true" />
            <rewrite>
                .....
            </rewrite>
           <security>
    		<requestFiltering allowDoubleEscaping="true"></requestFiltering>
    		 
    	</security>
        </system.webServer>
    <system.web>
    	<httpRuntime requestPathInvalidCharacters="" requestValidationMode="2.0" />
        <pages validateRequest="false" />
    </system.web>
    </configuration>


    Hope it can help you.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, December 23, 2013 4:20 AM
  • User-845709154 posted

    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?

    Wednesday, January 22, 2014 3:43 AM