странная кодировка строки запроса - PullRequest
0 голосов
/ 05 сентября 2018

Я создал две страницы aspx для демонстрации,

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();
    }

и затем я использовал Fiddler для отслеживания Интернета, нажал кнопку тестирования и затем нажал кнопку назад.

#   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  

мы могли видеть, что тела URL имеют странную кодировку, почему сгенерировал% u00f6? это может быть обратно к% c3% b6?

и когда мы нажимали кнопку «Назад», чтобы вернуться на страницу 1, его реферер пропал На самом деле я думаю, что странная кодировка вызвала проблему, потому что, когда я использовал инструменты разработчика F12, чтобы изменить действие (с «% u00f6» на «% c3% b6»), а затем нажал кнопку «Назад», был создан реферер.

нажмите здесь, чтобы увидеть скриншот

очень признателен вам, если вы можете дать ответ.

1 Ответ

0 голосов
/ 05 сентября 2018

Кодирование является стандартным. Согласно RFC 3986 .

2,4. Когда кодировать или декодировать

В обычных условиях единственный раз, когда октеты в URI
в процентах кодируется во время процесса создания URI из
его составные части. Это когда реализация определяет, какие зарезервированных символов должны использоваться в качестве разделителей подкомпонентов
и которые могут быть безопасно использованы в качестве данных. После создания URI всегда в процентном кодировании.

При разыменовании URI компоненты и подкомпоненты
имеет значение для процесса разыменования для конкретной схемы (если есть)
должны быть проанализированы и разделены до октетов в процентах эти компоненты могут быть безопасно декодированы, в противном случае данные могут быть
ошибочно принят за разделители компонентов. Единственное исключение для
октеты в процентах, соответствующие символам в незарезервированном
набор, который можно декодировать в любое время. Например, октет
соответствующий символу тильды ("~") часто кодируется как "% 7E"
старыми реализациями обработки URI; «% 7E» можно заменить на «~» без изменения его интерпретации.

Поскольку символ процента («%») служит индикатором для
октеты в процентах, для этого он должен быть в процентах как "% 25"
октет для использования в качестве данных в URI. Реализации не должны
процентное кодирование или декодирование одной и той же строки более одного раза, как при декодировании
уже декодированная строка может привести к неверной интерпретации процента
октет данных как начало кодирования процентов или наоборот в
случай процентного кодирования уже закодированной в процентах строки.

Вы также можете использовать www.urlencoder.org , чтобы увидеть ожидаемый URL-кодированный вывод, если вы хотите провести некоторое тестирование.

Относительно того, почему реферер пропал, вы можете взглянуть на . В каких случаях HTTP_REFERER будет пустым .

Он будет / может быть пустым, когда конечный пользователь

  • ввел URL сайта в адресную строку браузера.
  • посетил сайт с помощью поддерживаемой браузером закладки.
  • посетил сайт как первую страницу в окне / вкладке.
  • нажал ссылку во внешнем приложении.
  • переключен с URL-адреса https на URL-адрес http.
  • переключен с URL-адреса https на другой URL-адрес https.
  • имеет установленное программное обеспечение безопасности (антивирус / брандмауэр / и т. Д.), Которое убирает реферера из всех запросов.
  • находится за прокси, который отбирает у реферера все запросы.
  • посещал сайт программно (например, curl) без установки заголовка реферера (поисковые роботы!).

После некоторого копания я увидел это из RFC 2616 .

14,36 Рефери

Поле заголовка запроса Referer [sic] позволяет клиенту указывать, для удобства сервера адрес (URI) ресурса, с которого Request-URI был получен («реферер», хотя заголовок поле с ошибкой.) Заголовок запроса Referer позволяет серверу генерировать списки обратных ссылок на ресурсы для интереса, регистрации, оптимизированное кеширование и т. д. Оно также допускает устаревшие или ошибочные ссылки на быть прослежены для обслуживания. Поле Referer НЕ ДОЛЖНО отправляться, если Request-URI был получен из источника, который не имеет своего собственного URI, например, ввод с клавиатуры пользователя.

Извлеките последнее предложение абзаца, я полагаю, что в вашем примере вы «изменили» кодировку.

Я использовал инструменты разработчика F12, чтобы изменить действие (с "% u00f6" на "% C3% b6")

...