Авторитетное положение повторяющихся ключей запроса HTTP GET

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

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

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

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

На это нет никаких спецификаций . Вы можете делать, что хотите.

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

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

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'

Могу подтвердить, что для 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.

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

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

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

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

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

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

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

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

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

Обычно повторяющиеся значения параметров, например

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

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

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

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

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

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

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