strange encoding to querystring

Question

i have created two aspx pages for the demo,

page1 - WebForm1.aspx

<asp:TextBox ID="txtTest" runat="server" Width="100px"></asp:TextBox>
<asp:Button ID="btnClick" runat="server" Text="test" Width="100px" OnClick="btnClick_Click"/>

    protected void Page_Load(object sender, EventArgs e)
    {
        if (!IsPostBack)
        {
            if (Request.QueryString["text"] == null || string.IsNullOrEmpty(Request.QueryString["text"].ToString()))
                txtTest.Text = "ö";
            else
                txtTest.Text = Request.QueryString["text"].ToString();
        }
    }

    public void btnClick_Click(object sender, EventArgs e)
    {
        HttpResponse response = HttpContext.Current.Response;
        response.Write(string.Format("<script>window.location = '{0}';</script>", HttpUtility.JavaScriptStringEncode("WebForm2.aspx?text=" + HttpUtility.UrlEncode(txtTest.Text))));
        response.End();
    }

page2 - WebForm2.aspx

<asp:TextBox ID="txtResult" runat="server" Width="200px"></asp:TextBox>
<asp:Button ID="btnBack" runat="server" Text="back" Width="50px" OnClick="btnBack_Click"/>

    protected void Page_Load(object sender, EventArgs e)
    {
        if (!IsPostBack)
        {
            if (Request.QueryString["text"] == null || string.IsNullOrEmpty(Request.QueryString["text"].ToString()))
                txtResult.Text = "empty";
            else
                txtResult.Text = Request.QueryString["text"].ToString();
        }
    }

    public void btnBack_Click(object sender, EventArgs e)
    {
        HttpResponse response = HttpContext.Current.Response;
        response.Write(string.Format("<script>window.location = '{0}';</script>", HttpUtility.JavaScriptStringEncode("WebForm1.aspx?text=" + HttpUtility.UrlEncode(txtResult.Text))));
        response.End();
    }

and then i used Fiddler to track the web, clicked test button and then clicked back button.

#   Result  Protocol    Host    URL Body    Caching Content-Type    Process Comments    Custom  
6   200 HTTP    localhost:56484 /WebForm2.aspx?text=%c3%b6  835 private text/html; charset=utf-8    iexplore:12316          
8   200 HTTP    localhost:56484 /WebForm2.aspx?text=%u00f6  175 private text/html; charset=utf-8    iexplore:12316          
9   200 HTTP    localhost:56484 /WebForm1.aspx?text=%c3%b6  830 private text/html; charset=utf-8    iexplore:12316          
10  200 HTTP    localhost:56484 /WebForm1.aspx?text=%u00f6  175 private text/html; charset=utf-8    iexplore:12316          
11  200 HTTP    localhost:56484 /WebForm2.aspx?text=%c3%b6  834 private text/html; charset=utf-8    iexplore:12316  

we could see the URL bodies have strange encoding, why did %u00f6 generate? can it be back to %c3%b6?

and when we were clicking back button to back to page1, its referrer became missing. Actually i think the strange encoding caused the issue, because when i used F12 Developer tools to change the action(from "%u00f6" to "%c3%b6"), and then clicked back button, the referrer was generated.

click here to see the screenshot

much appreciate to you if you can give the answer.

Answer 1

The encoding behavior is a standard. As per RFC 3986.

2.4. When to Encode or Decode

Under normal circumstances, the only time when octets within a URI
are percent-encoded is during the process of producing the URI from
its component parts. This is when an implementation determines which of the reserved characters are to be used as subcomponent delimiters
and which can be safely used as data. Once produced, a URI is always in its percent-encoded form.

When a URI is dereferenced, the components and subcomponents
significant to the scheme-specific dereferencing process (if any)
must be parsed and separated before the percent-encoded octets within those components can be safely decoded, as otherwise the data may be
mistaken for component delimiters. The only exception is for
percent-encoded octets corresponding to characters in the unreserved
set, which can be decoded at any time. For example, the octet
corresponding to the tilde ("~") character is often encoded as "%7E"
by older URI processing implementations; the "%7E" can be replaced by "~" without changing its interpretation.

Because the percent ("%") character serves as the indicator for
percent-encoded octets, it must be percent-encoded as "%25" for that
octet to be used as data within a URI. Implementations must not
percent-encode or decode the same string more than once, as decoding
an already decoded string might lead to misinterpreting a percent
data octet as the beginning of a percent-encoding, or vice versa in
the case of percent-encoding an already percent-encoded string.

You can also use www.urlencoder.org to see the expected url encoded output if you want to do some testing.

As to why the referrer became missing, you can take a look at In what cases will HTTP_REFERER be empty.

It will/may be empty when the enduser

• entered the site URL in browser address bar itself.
• visited the site by a browser-maintained bookmark.
• visited the site as first page in the window/tab.
• clicked a link in an external application.
• switched from a https URL to a http URL.
• switched from a https URL to a different https URL.
• has security software installed (antivirus/firewall/etc) which strips the referrer from all requests.
• is behind a proxy which strips the referrer from all requests.
• visited the site programmatically (like, curl) without setting the referrer header (searchbots!).

After some digging I saw this from the RFC 2616.

14.36 Referer

The Referer[sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained (the "referrer", although the header field is misspelled.) The Referer request-header allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. It also allows obsolete or mistyped links to be traced for maintenance. The Referer field MUST NOT be sent if the Request-URI was obtained from a source that does not have its own URI, such as input from the user keyboard.

Checkout the last sentence of the paragraph, I believe that in your example you "changed" the encoding.

i used F12 Developer tools to change the action(from "%u00f6" to "%c3%b6")