Строка запроса является частью унифицированного локатора ресурсов (URL), который присваивает значения указанным параметрам. Строка запроса обычно включает поля, добавляемые к базовому URL веб-браузером или другим клиентским приложением, например, как часть HTML-документа, выбора внешнего вида страницы или перехода к позициям в мультимедийном контенте.
title=Query_string&action=editВеб-сервер может обрабатывать запрос протокола передачи гипертекста (HTTP) либо путем чтения файла из своей файловой системы на основе пути URL , либо путем обработки запроса с использованием логики, специфичной для типа ресурса. В случаях, когда вызывается специальная логика, строка запроса будет доступна этой логике для использования в ее обработке вместе с компонентом пути URL.
Типичный URL, содержащий строку запроса, выглядит следующим образом:
https://example.com/over/there?name=ferret
Когда сервер получает запрос на такую страницу, он может запустить программу, передавая строку запроса, которая в данном случае является name=ferret, без изменений в программу. Вопросительный знак используется как разделитель и не является частью строки запроса. [1] [2]
Веб-фреймворки могут предоставлять методы для анализа нескольких параметров в строке запроса, разделенных каким-либо разделителем. [3] В примере URL ниже несколько параметров запроса разделены амперсандом , " &":
https://example.com/path/to/page?name=ferret&color=purple
Точная структура строки запроса не стандартизирована. Методы, используемые для разбора строки запроса, могут различаться между веб-сайтами.
Ссылка на веб-странице может иметь URL, содержащий строку запроса. 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). [4] [5]
Для каждого поля формы строка запроса содержит пару . Веб-формы могут включать поля, которые не видны пользователю; эти поля включаются в строку запроса при отправке формы.field=value
Это соглашение является рекомендацией W3C . [3] В рекомендациях 1999 года W3C рекомендовал, чтобы все веб-серверы поддерживали разделители в виде точки с запятой в дополнение к разделителям -амперсандам [6], чтобы разрешить строки запросов application/x-www-form-urlencoded в URL-адресах в документах HTML без необходимости экранирования амперсандов. С 2014 года W3C рекомендует использовать в качестве разделителя запросов только амперсанд . [7]
Содержимое формы кодируется в строке запроса URL только тогда, когда метод отправки формы — GET . Та же кодировка используется по умолчанию, когда метод отправки — POST , но результат отправляется как тело HTTP-запроса, а не включается в измененный URL. [8]
До того, как формы были добавлены в HTML, браузеры отображали <isindex>элемент – как однострочный элемент управления вводом текста. Текст, введенный в этот элемент управления, отправлялся на сервер как дополнение к строке запроса к запросу GET для базового URL или другого URL, указанного атрибутом action. [9] Это было сделано для того, чтобы позволить веб-серверам использовать предоставленный текст в качестве критериев запроса, чтобы они могли вернуть список соответствующих страниц. [10]
При отправке текстового ввода в индексированный элемент управления поиском он кодируется как строка запроса следующим образом:
argument1+argument2+argument3...
+'.Хотя <isindex>элемент устарел и большинство браузеров больше не поддерживают или не отображают его, все еще существуют некоторые остатки индексированного поиска. Например, это источник специальной обработки знака плюса , ' +' в процентном кодировании URL браузера (которое сегодня, с прекращением поддержки индексированного поиска, является практически избыточным с %20). Также некоторые веб-серверы, поддерживающие CGI (например, Apache ), будут обрабатывать строку запроса в аргументы командной строки, если она не содержит знака равенства , ' =' (согласно разделу 4.4 CGI 1.1). Некоторые скрипты CGI все еще зависят от этого исторического поведения и используют его для URL-адресов, встроенных в HTML.
Некоторые символы не могут быть частью URL (например, пробел), а некоторые другие символы имеют особое значение в URL: например, символ #может использоваться для дальнейшего указания подраздела (или фрагмента ) документа. В формах HTML символ =используется для отделения имени от значения. Общий синтаксис URI использует кодировку URL для решения этой проблемы, в то время как формы HTML делают некоторые дополнительные замены вместо применения процентной кодировки для всех таких символов. ПРОБЕЛ кодируется как ' +' или " %20". [11]
HTML 5 определяет следующее преобразование для отправки HTML-форм с методом "GET" на веб-сервер. Ниже приводится краткое изложение алгоритма:
+' или ' %20'A– Zи a– z), цифры ( 0– 9) и символы ' ~',' -',' .' и ' _' остаются без изменений.+закодирован %2B%HH шестнадцатеричном представлении, при этом все символы, не входящие в ASCII, сначала кодируются в UTF-8 (или другой указанной кодировке).Октет, соответствующий тильде (" ~"), разрешен в строках запроса RFC3986, но в формах HTML его необходимо кодировать процентами в " %7E".
Кодирование ПРОБЕЛА как ' +' и выбор символов «как есть» отличает эту кодировку от RFC 3986.
Если форма встроена в HTML- страницу следующим образом:
< действие формы = "/cgi-bin/test.cgi" метод = "получить" > < тип ввода = "текст" имя = "первый" /> < тип ввода = "текст" имя = "второй" /> < тип ввода = "отправить" /> </ форма > и пользователь вставляет строки «это поле» и «было ли это понятно (уже)?» в два текстовых поля и нажимает кнопку отправки, программа (программа ,test.cgi указанная атрибутом action элемента в приведенном выше примере) получит следующую строку запроса: .form first=this+is+a+field&second=was+it+clear+%28already%29%3F
Если форма обрабатывается на сервере с помощью CGI- скрипта , скрипт обычно может получать строку запроса в виде переменной среды с именем QUERY_STRING.
Программа, получающая строку запроса, может игнорировать ее часть или всю. Если запрошенный URL соответствует файлу, а не программе, вся строка запроса игнорируется. Однако, независимо от того, используется строка запроса или нет, весь URL, включая ее, сохраняется в файлах журнала сервера .
Эти факты позволяют использовать строки запроса для отслеживания пользователей способом, аналогичным тому, который предоставляют HTTP-cookie . Чтобы это работало, каждый раз, когда пользователь загружает страницу, необходимо выбрать уникальный идентификатор и добавить его в качестве строки запроса к URL-адресам всех ссылок, содержащихся на странице. Как только пользователь переходит по одной из этих ссылок, соответствующий URL-адрес запрашивается на сервере. Таким образом, загрузка этой страницы связывается с предыдущей.
Например, при запросе веб-страницы, содержащей следующее:
<a href="foo.html"> посмотрите мою страницу ! </a> <a href="bar.html"> моя лучше </a> выбирается уникальная строка, например e0a72cb2a2c7, и страница изменяется следующим образом:
< a href = "foo.html?e0a72cb2a2c7" > посмотрите мою страницу! </ a > < a href = "bar.html?e0a72cb2a2c7" > моя лучше </ a >Добавление строки запроса не меняет способ показа страницы пользователю. Когда пользователь переходит, например, по первой ссылке, браузер запрашивает страницу foo.html?e0a72cb2a2c7у сервера, который игнорирует то, что следует далее ?, и отправляет страницу foo.htmlкак и ожидалось, также добавляя строку запроса к своим ссылкам.
Таким образом, любой последующий запрос страницы от этого пользователя будет содержать ту же строку запроса e0a72cb2a2c7, что позволяет установить, что все эти страницы были просмотрены одним и тем же пользователем. Строки запроса часто используются совместно с веб-маяками .
Основные различия между строками запросов, используемыми для отслеживания, и файлами cookie HTTP заключаются в следующем:
Согласно спецификации HTTP :
На практике встречаются различные специальные ограничения на длину строки запроса. РЕКОМЕНДУЕТСЯ, чтобы все отправители и получатели HTTP поддерживали, как минимум, длину строки запроса в 8000 октетов. [13]
Если URL-адрес слишком длинный, веб-сервер выдает ошибку с кодом состояния HTTP 414 Request-URI Too Long .
Обычным решением этих проблем является использование POST вместо GET и сохранение параметров в теле запроса. Ограничения по длине тел запросов обычно намного выше, чем ограничения по длине URL. Например, ограничение по размеру POST по умолчанию составляет 2 МБ на IIS 4.0 и 128 КБ на IIS 5.0. Ограничение настраивается на Apache2 с помощью директивы LimitRequestBody, которая указывает количество байтов от 0 (что означает неограниченно) до 2147483647 (2 ГБ), которые разрешены в теле запроса. [14]