Официальная позиция дублированных ключей запроса HTTP GET

Question

У меня проблемы с поиском достоверной информации о поведении с помощью повторяющихся полей строки запроса HTTP GET, например

http://example.com/page?field=foo&field=bar 

и, в частности, если заказ сохранен или нет. Большинство веб-ориентированных языков создают массив, содержащий как foo, так и bar, связанные с ключевым «полем», но я хотел бы знать, существует ли авторитетное утверждение (например, в RFC) по этому вопросу. RFC 3986 имеет раздел 3.4. Query, который ссылается на пары ключ = значение, но ничего не говорится о том, как интерпретировать порядок и дублировать поля и так далее. Это имеет смысл, поскольку оно зависит от бэкэнда, а не в рамках этого RFC ...

Хотя существует де-факто стандарт, я хотел бы увидеть его авторитетный источник, просто из любопытства.

Answer 1

Там нет спецификации на этом. Вы можете делать то, что вам нравится.

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

Предположим, что необработанный запрос:

GET /blog/posts?tag=ruby&tag=rails HTTP/1.1
Host: example.com

Тогда есть различные варианты того, что request.query['tag'] должно дать, в зависимости от языка или структуры:

request.query['tag'] => 'ruby'
request.query['tag'] => 'rails'
request.query['tag'] => ['ruby', 'rails']
request.query['tag'] => 'ruby,rails'

Answer 2

Я могу подтвердить, что для PHP (по крайней мере, в версии 4.4.4 и новее) это работает так:

GET /blog/posts?tag=ruby&tag=rails HTTP/1.1
Host: example.com

Результат:

request.query['tag'] => 'rails'

Но

GET /blog/posts?tag[]=ruby&tag[]=rails HTTP/1.1
Host: example.com

Результат:

request.query['tag'] => ['ruby', 'rails']

Это поведение одинаково для данных GET и POST.

Answer 3

Ответ Ифельдблюма идеален.

Просто заметка о пятом поведении, которое я недавно заметил: на Windows Phone , открытие приложения с URI с дублирующим ключом запроса приведет к NavigationFailed с:

System.ArgumentException: элемент с тем же ключом уже был добавлен.

Виновник System.Windows.Navigation.UriParsingHelper.InternalUriParseQueryStringToDictionary(Uri uri, Boolean decodeResults).

Так что система даже не позволит вам справиться с этим так, как вы хотите, она запретит это. Вам остается только одно решение - выбрать собственный формат (CSV, JSON, XML, ...) и uri-escape-it.

Answer 4

Большинство (все?) Платформ не дают никаких гарантий, поэтому предположим, что они будут возвращены в случайном порядке.

Всегда выбирай самый безопасный подход.

Например, интерфейс Java HttpServlet: ServletRequest.html # getParameterValues ​​

Даже метод getParameterMap не упоминает о порядке параметров (на порядок итератора java.util.Map нельзя полагаться.)

Answer 5

Как правило, повторяющиеся значения параметров, такие как

http://example.com/page?field=foo&field=bar

приводит к одному параметру queryString, который является массивом:

field[0]=='foo'
field[1]=='bar'

Я видел такое поведение в ASP, ASP.NET и PHP4.

Answer 6

У меня был тот же вопрос. Я пишу функцию JavaScript для анализа и строковых запросов. Я не знаю, является ли строка запроса дублирующими именами или имя в скобках, например x [] = 1 & x [] = 2, является стандартным, хотя некоторые языки поддерживают этот формат.

Но я обнаружил, что в Chrome и Firefox появился новый класс с именем URLSeachParams, и он поддерживает только самый простой формат как name=value. Если в строке запроса есть повторяющиеся имена, метод get из URLSearchParams возвращает только первое.

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