Строка запроса является частью унифицированного указателя ресурса (URL) , который присваивает значения указанных параметров. Строка запроса обычно включает поля, добавленные к базовому URL-адресу веб-браузером или другим клиентским приложением, например, как часть HTML-формы . [1]
Веб-сервер может обрабатывать запрос протокола передачи гипертекста (HTTP) либо путем чтения файла из своей файловой системы на основе пути URL, либо путем обработки запроса с использованием логики, специфичной для типа ресурса. В случаях, когда вызывается специальная логика, строка запроса будет доступна этой логике для использования при ее обработке вместе с компонентом пути URL-адреса.
Структура [ править ]
Типичный URL-адрес, содержащий строку запроса, выглядит следующим образом:
https://example.com/over/there?name=ferret
Когда сервер получает запрос на такую страницу, он может запустить программу, передав ей строку запроса, которая в данном случае остается name=ferret
неизменной. Знак вопроса используется как разделитель и не является частью строки запроса. [2] [3]
Веб-фреймворки могут предоставлять методы для анализа нескольких параметров в строке запроса, разделенных некоторым разделителем. [4] В приведенном ниже примере 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...
- Строка запроса состоит из серии пар "поле-значение".
- В каждой паре имя поля и значение разделяются знаком равенства "
=
". - Серии пар разделяются амперсандом "
&
" (или точкой с запятой ";
" для URL-адресов, встроенных в HTML и не генерируемых a<form>...</form>
. См. Ниже).
Хотя окончательного стандарта не существует, большинство веб-фреймворков позволяют связывать несколько значений с одним полем (например, field1=value1&field1=value2&field2=value3
). [5] [6]
Для каждого поля формы строка запроса содержит пару . Веб-формы могут включать поля, которые не видны пользователю; эти поля включаются в строку запроса при отправке формыfield=value
Это соглашение является рекомендацией W3C . [4] W3C рекомендует, чтобы все веб-серверы поддерживали разделители точки с запятой в дополнение к разделителям амперсанд [7], чтобы разрешить строки запроса с кодом application / x-www-form-urlencoded в URL-адресах в документах HTML без необходимости экранирования амперсандов.
Содержимое формы кодируется в строке запроса URL-адреса только в том случае, если метод отправки формы - GET . Такая же кодировка используется по умолчанию, когда метод отправки - POST , но результат отправляется как тело HTTP-запроса, а не включается в измененный URL-адрес. [1]
Индексированный поиск [ править ]
До того, как формы были добавлены в HTML, браузеры отображали <isindex>
элемент как однострочный элемент управления вводом текста. Текст, введенный в этот элемент управления, был отправлен на сервер как дополнение строки запроса к запросу GET для базового URL-адреса или другого URL-адреса, указанного в action
атрибуте. [8] Это было предназначено для того, чтобы позволить веб-серверам использовать предоставленный текст в качестве критериев запроса, чтобы они могли возвращать список совпадающих страниц. [9]
Когда текст, вводимый в элемент управления индексированным поиском, передается, он кодируется как строка запроса следующим образом:
argument1+argument2+argument3...
- Строка запроса состоит из серии аргументов путем разбора текста на слова в пробелах.
- Серии разделяются знаком плюс '
+
'.
Хотя этот <isindex>
элемент устарел, и большинство браузеров больше не поддерживают и не отображают его, все еще существуют остатки индексированного поиска. Например, это источник специальной обработки знака «плюс » +
в процентной кодировке URL-адресов браузера (которая сегодня, с отказом от индексированного поиска, практически избыточна %20
). Также некоторые веб-серверы, поддерживающие CGI (например, Apache ), будут преобразовывать строку запроса в аргументы командной строки, если она не содержит знака равенства ' =
' (согласно разделу 4.4 CGI 1.1). Некоторые сценарии CGI все еще зависят и используют это историческое поведение для URL-адресов, встроенных в HTML.
Кодировка URL [ править ]
Некоторые символы не могут быть частью URL-адреса (например, пробел), а некоторые другие символы имеют особое значение в URL-адресе: например, символ #
может использоваться для дальнейшего указания подраздела (или фрагмента ) документа. В формах HTML символ =
используется для отделения имени от значения. В универсальном синтаксисе URI для решения этой проблемы используется кодирование URL-адресов , а в формах HTML для всех таких символов выполняются некоторые дополнительные замены, а не применяется процентное кодирование. ПРОБЕЛ кодируется как ' +
' или " %20
". [10]
HTML 5 определяет следующее преобразование для отправки HTML-форм с помощью метода «GET» на веб-сервер. [1] Ниже приводится краткое описание алгоритма:
- Символы, которые невозможно преобразовать в правильную кодировку, заменяются ссылками на числовые символы HTML [11]
- ПРОБЕЛ кодируется как '
+
' или '%20
' - Буквы (
A
-Z
иa
-z
), цифры (0
-9
) и символы '~
', '-
', '.
' и '_
' оставляются как есть. +
кодируется% 2B- Все остальные символы кодируются как
%HH
шестнадцатеричное представление с любыми символами, отличными от ASCII, сначала закодированными как UTF-8 (или в другой указанной кодировке).
Октет, соответствующий тильде (" ~
"), разрешен в строках запроса RFC3986, но должен быть закодирован в процентах в HTML-формах как " %7E
".
Кодирование SPACE as ' +
' и выбор символов "как есть" отличает эту кодировку от 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 >
и пользователь вставляет строки «это поле» и «было ли это ясно (уже)?» в двух текстовых полей и нажимают кнопку Submit, программа 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 запрашивается на сервере. Таким образом, загрузка этой страницы будет связана с предыдущей.
Например, когда запрашивается веб-страница, содержащая следующее:
< HREF = "foo.html" > видеть мою страницу! </ > < HREF = "bar.html" > шахта лучше </ >
e0a72cb2a2c7
выбирается уникальная строка, например, как , и страница изменяется следующим образом:
< HREF = "foo.html? E0a72cb2a2c7" > видеть мою страницу! </ > < HREF = "bar.html? E0a72cb2a2c7" > шахта лучше </ >
Добавление строки запроса не меняет способ отображения страницы пользователю. Когда пользователь следует, например, по первой ссылке, браузер запрашивает страницу foo.html?e0a72cb2a2c7
на сервере, который игнорирует то, что следует, ?
и отправляет страницу, foo.html
как ожидалось, добавляя строку запроса к своим ссылкам.
Таким образом, любой последующий запрос страницы от этого пользователя будет содержать ту же строку запроса e0a72cb2a2c7
, что позволит установить, что все эти страницы были просмотрены одним и тем же пользователем. Строки запроса часто используются вместе с веб-маяками .
Основные различия между строками запроса, используемыми для отслеживания, и файлами cookie HTTP заключаются в следующем:
- Строки запроса составляют часть URL-адреса и поэтому включаются, если пользователь сохраняет или отправляет URL-адрес другому пользователю; Файлы cookie могут поддерживаться во время сеансов просмотра, но не сохраняются и не отправляются с URL-адресом.
- Если пользователь переходит на один и тот же веб-сервер двумя (или более) независимыми путями, ему будут назначены две разные строки запроса, а сохраненные файлы cookie будут одинаковыми.
- Пользователь может отключить файлы cookie, и в этом случае использование файлов cookie для отслеживания не работает. Однако использование строк запроса для отслеживания должно работать во всех ситуациях.
- Различные строки запроса, передаваемые при разных посещениях страницы, будут означать, что страницы никогда не обслуживаются из кеша браузера (или прокси-сервера, если он есть), тем самым увеличивая нагрузку на веб-сервер и замедляя взаимодействие с пользователем.
Проблемы совместимости [ править ]
Согласно спецификации HTTP :
На практике встречаются различные специальные ограничения на длину строки запроса. РЕКОМЕНДУЕТСЯ, чтобы все отправители и получатели HTTP поддерживали как минимум длину строки запроса 8000 октетов. [12]
Если URL-адрес слишком длинный, веб-сервер выдает ошибку с кодом состояния HTTP 414 Request-URI Too Long .
Обычный способ решения этих проблем - использовать POST вместо GET и сохранить параметры в теле запроса. Пределы длины тела запроса обычно намного выше, чем ограничения длины URL. Например, ограничение на размер POST по умолчанию составляет 2 МБ для IIS 4.0 и 128 КБ для IIS 5.0. Предел настраивается на Apache2 с помощью LimitRequestBody
директивы, которая определяет количество байтов от 0 (то есть неограниченно) до 2147483647 (2 ГБ), которые разрешены в теле запроса. [13]
См. Также [ править ]
- Чистый URL
- Идентификатор клика
- Общий интерфейс шлюза (CGI)
- HTTP cookie
- Протокол передачи гипертекста (HTTP)
- Семантические URL
- Схема URI
- Параметры UTM
- Веб-маяк
Ссылки [ править ]
- ^ a b c [1] , HTML5.2, рекомендация W3C, 14 декабря 2017 г.
- ^ Т. Бернерс-Ли; Р. Филдинг; Л. Масинтер (январь 2005 г.). «RFC 3986» . «Компоненты синтаксиса» (раздел 3).
- ^ Т. Бернерс-Ли; Р. Филдинг; Л. Масинтер (январь 2005 г.). «RFC 3986» . «Запрос» (раздел 3.4).
- ^ a b Формы в HTML-документах . W3.org. Проверено 8 сентября 2013.
- ^ "ServletRequest (Java EE 6)" . docs.oracle.com . 2011-02-10 . Проверено 8 сентября 2013 .
- ^ "uri - Авторитетное положение повторяющихся ключей запроса HTTP GET" . Переполнение стека . 2013-06-09 . Проверено 8 сентября 2013 .
- ^ Замечания по производительности, реализации и дизайну . W3.org. Проверено 8 сентября 2013.
- ^ "<isindex>" . HTML (язык разметки гипертекста) .
- ^ "HTML / Elements / isindex" . W3C Wiki .
- ^ «Справочник по кодировке URL-адресов HTML» . W3Schools . Проверено 1 мая 2013 года .
- ^ Применение / х-WWW-форм-urlencoded кодирование алгоритма , HTML5.2, рекомендации W3C, 14 декабря 2017
- ^ HTTP / 1.1 Синтаксис сообщений и маршрутизация . ietf.org. Проверено 31 июля 2014.
- ^ core - HTTP-сервер Apache . Httpd.apache.org. Проверено 8 сентября 2013.
Внешние ссылки [ править ]
- RFC 3986 https://sspool.herokuapp.com/clash/proxies