Строка запроса

Строка запроса — это часть универсального указателя ресурсов (URL), который присваивает значения указанным параметрам. Строка запроса обычно включает поля, добавленные к базовому URL-адресу веб-браузером или другим клиентским приложением, например, как часть HTML-документа, выбора внешнего вида страницы или перехода к позициям в мультимедийном контенте.

Адресная строка в Google Chrome, показывающая URL-адрес со строкой запроса. title=Query_string&action=edit

Веб-сервер может обрабатывать запрос протокола передачи гипертекста (HTTP) либо путем чтения файла из своей файловой системы на основе URL- пути, либо путем обработки запроса с использованием логики, специфичной для типа ресурса. В случаях, когда вызывается специальная логика, строка запроса будет доступна этой логике для использования в ее обработке вместе с компонентом пути URL-адреса.

Структура

Типичный URL-адрес, содержащий строку запроса, выглядит следующим образом:

https://example.com/over/there?name=ferret

Когда сервер получает запрос на такую ​​страницу, он может запустить программу, передав строку запроса, которая в данном случае имеет вид name=ferret, без изменений в программе. Вопросительный знак используется в качестве разделителя и не является частью строки запроса.

Веб-платформы могут предоставлять методы для анализа нескольких параметров в строке запроса, разделенных некоторым разделителем. В приведенном ниже примере URL-адреса несколько параметров запроса разделены амперсандом " &":

https://example.com/path/to/page?name=ferret&color=purple

Точная структура строки запроса не стандартизирована. Методы, используемые для анализа строки запроса, могут различаться на разных веб-сайтах.

Ссылка на веб-странице может иметь URL-адрес, содержащий строку запроса. HTML определяет три способа, которыми пользовательский агент может генерировать строку запроса:

• форму HTML- через <form>...</form> элемент
• сервера карта изображений на стороне через ismap атрибут на <img> элемент с <img ismap> строительство
• индексированный поиск через устаревший <isindex> элемент

Веб-формы

Одним из первоначальных вариантов использования было хранение содержимого HTML-формы , также известной как веб-форма. В частности, когда форма, содержащая поля field1, field2, field3 отправляется, содержимое полей кодируется как строка запроса следующим образом:

field1=value1&field2=value2&field3=value3...

• Строка запроса состоит из серии пар «поле-значение».
• Внутри каждой пары имя и значение поля разделяются знаком равенства : " =".
• Ряд пар отделяется амперсандом , " &"( точки с запятой " ;" больше не рекомендуются W3C , см. ниже).

Хотя не существует четкого стандарта, большинство веб-фреймворков позволяют связать несколько значений с одним полем (например, field1=value1&field1=value2&field2=value3).

Для каждого поля формы строка запроса содержит пару field=value. Веб-формы могут включать поля, невидимые пользователю; эти поля включаются в строку запроса при отправке формы.

Это соглашение является рекомендацией W3C . В рекомендациях 1999 года W3C рекомендовал, чтобы все веб-серверы поддерживали разделители точка с запятой в дополнение к амперсанда. разделителям чтобы разрешить строки запроса application/x-www-form-urlencoded в URL-адресах в HTML-документах без необходимости экранирования амперсандов. С 2014 года W3C рекомендует использовать в качестве разделителя запросов только амперсанд .

Содержимое формы кодируется в строке запроса URL-адреса только в том случае, если методом отправки формы является GET . Та же кодировка используется по умолчанию, когда методом отправки является POST , но результат отправляется как тело HTTP-запроса, а не включается в измененный URL-адрес.

Индексированный поиск

До того, как формы были добавлены в HTML, браузеры отображали: <isindex> элемент как однострочный элемент управления вводом текста. Текст, введенный в этот элемент управления, был отправлен на сервер как дополнение строки запроса к запросу GET для базового URL-адреса или другого URL-адреса, указанного action атрибут. Это было сделано для того, чтобы веб-серверы могли использовать предоставленный текст в качестве критерия запроса и возвращать список совпадающих страниц.

Когда текстовый ввод в элемент управления индексированным поиском отправляется, он кодируется как строка запроса следующим образом:

argument1+argument2+argument3...

• Строка запроса состоит из ряда аргументов путем анализа текста на слова через пробелы.
• Серия отделяется знаком плюс , ' +'.

Хотя <isindex> элемент устарел, и большинство браузеров больше не поддерживают и не отображают его, некоторые остатки индексированного поиска все еще существуют. Например, это источник специальной обработки знака плюс : ' +' внутри процентной кодировки URL-адреса браузера (которая сегодня, с прекращением индексированного поиска, практически ненужна с %20). Также некоторые веб-серверы, поддерживающие CGI (например, Apache ), преобразуют строку запроса в аргументы командной строки, если она не содержит знака равенства , ' =' (согласно разделу 4.4 CGI 1.1). Некоторые сценарии CGI по-прежнему зависят от этого исторического поведения и используют его для URL-адресов, встроенных в HTML.

URL-кодирование

Основная статья: Процентное кодирование

Некоторые символы не могут быть частью URL-адреса (например, пробел), а некоторые другие символы имеют в URL-адресе особое значение: например, символ # может использоваться для дальнейшего указания подраздела (или фрагмента ) документа. В формах HTML символ = используется для отделения имени от значения. Общий синтаксис URI использует кодировку URL для решения этой проблемы, в то время как HTML-формы делают некоторые дополнительные замены вместо применения процентного кодирования для всех таких символов. ПРОСТРАНСТВО кодируется как ' +' или " %20".

HTML 5 определяет следующее преобразование для отправки HTML-форм с помощью метода GET на веб-сервер. Ниже приводится краткое изложение алгоритма:

• Символы, которые невозможно преобразовать в правильную кодировку, заменяются ссылками на числовые символы HTML.
• ПРОСТРАНСТВО кодируется как ' +' или ' %20'
• Письма ( A– Z и a– z), числа ( 0– 9) и персонажи ' ~',' -',' .' и ' _' оставлены как есть
• + закодирован %2B
• Все остальные символы кодируются как %HH шестнадцатеричное представление с любыми символами, отличными от ASCII, сначала закодированными как UTF-8 (или другая указанная кодировка)

Октет, соответствующий тильде (" ~") разрешено в строках запроса согласно RFC3986, но должно быть закодировано в процентах в формах HTML, чтобы " %7E".

Кодировка SPACE как ' +', а выбор символов «как есть» отличает эту кодировку от RFC 3986.

Пример

Если форма встроена в HTML- страницу следующим образом:

<form action="/cgi-bin/test.cgi" method="get">
  <input type="text" name="first" />
  <input type="text" name="second" />
  <input type="submit" />
</form>

и пользователь вставляет строки «это поле» и «было ясно (уже)?» в двух текстовых полях и нажимает кнопку отправки, программа test.cgi (программа, указанная action атрибут ​ form элемент в приведенном выше примере) получит следующую строку запроса: first=this+is+a+field&second=was+it+clear+%28already%29%3F.

форма обрабатывается на сервере сценарием CGI Если , сценарий обычно может получить строку запроса в виде переменной среды с именем QUERY_STRING.

Отслеживание

Программа, получающая строку запроса, может игнорировать ее часть или всю. Если запрошенный URL-адрес соответствует файлу, а не программе, вся строка запроса игнорируется. Однако независимо от того, используется строка запроса или нет, весь URL-адрес, включая ее, сохраняется в файлах журнала сервера .

Эти факты позволяют использовать строки запроса для отслеживания пользователей аналогично тому, как это обеспечивается с помощью файлов cookie HTTP . Чтобы это работало, каждый раз, когда пользователь загружает страницу, необходимо выбрать уникальный идентификатор и добавить его в виде строки запроса к URL-адресам всех ссылок, содержащихся на странице. Как только пользователь переходит по одной из этих ссылок, на сервер запрашивается соответствующий URL-адрес. Таким образом, загрузка этой страницы связана с предыдущей.

Например, когда запрашивается веб-страница, содержащая следующее:

 <a href="foo.html">see my page!</a>
 <a href="bar.html">mine is better</a>

уникальная строка, например e0a72cb2a2c7 выбирается, и страница изменяется следующим образом:

 <a href="foo.html?e0a72cb2a2c7">see my page!</a>
 <a href="bar.html?e0a72cb2a2c7">mine is better</a>

Добавление строки запроса не меняет способ отображения страницы пользователю. Когда пользователь переходит, например, по первой ссылке, браузер запрашивает страницу foo.html?e0a72cb2a2c7 на сервер, который игнорирует следующее ? и отправляет страницу foo.html как и ожидалось, добавив также строку запроса к его ссылкам.

Таким образом, любой последующий запрос страницы от этого пользователя будет содержать ту же строку запроса. e0a72cb2a2c7, позволяющий установить, что все эти страницы просматривал один и тот же пользователь. Строки запроса часто используются вместе с веб-маяками .

Основные различия между строками запроса, используемыми для отслеживания, и файлами cookie HTTP заключаются в следующем:

1. Строки запроса составляют часть URL-адреса и поэтому включаются, если пользователь сохраняет или отправляет URL-адрес другому пользователю; файлы cookie могут сохраняться во время сеансов просмотра, но не сохраняются и не отправляются вместе с URL-адресом.
2. Если пользователь попадает на один и тот же веб-сервер по двум (или более) независимым путям, ему будут назначены две разные строки запроса, при этом сохраненные файлы cookie будут одинаковыми.
3. Пользователь может отключить файлы cookie, и в этом случае использование файлов cookie для отслеживания не работает. Однако использование строк запроса для отслеживания должно работать во всех ситуациях.
4. Различные строки запроса, передаваемые при разных посещениях страницы, будут означать, что страницы никогда не обслуживаются из кеша браузера (или прокси-сервера, если он есть), что увеличивает нагрузку на веб-сервер и замедляет работу пользователя.

Проблемы совместимости

Согласно спецификации HTTP :

На практике встречаются различные специальные ограничения на длину строки запроса. РЕКОМЕНДУЕТСЯ, чтобы все отправители и получатели HTTP поддерживали длину строки запроса как минимум 8000 октетов.

Если URL-адрес слишком длинный, веб-сервер выходит из строя с кодом состояния HTTP 414 Request-URI Too Long .

Обычное решение этих проблем — использовать POST вместо GET и сохранять параметры в теле запроса. Ограничения на длину тела запроса обычно намного выше, чем ограничения на длину URL-адреса. Например, ограничение размера POST по умолчанию составляет 2 МБ в IIS 4.0 и 128 КБ в IIS 5.0. Ограничение настраивается на Apache2 с помощью LimitRequestBody директива, которая определяет количество байтов от 0 (что означает неограниченное) до 2147483647 (2 ГБ), разрешенных в теле запроса.

См. также

• URI фрагмента
• Нормализация URI
• URL (унифицированный указатель ресурсов)
• Очистить URL-адрес
• Идентификатор клика
• Общий интерфейс шлюза (CGI)
• HTTP-куки
• Протокол передачи гипертекста (HTTP)
• Семантические URL-адреса
• Схема URI
• UTM-параметры
• Веб-маяк