Autorytatywna pozycja zduplikowanych kluczy zapytań HTTP GET

Mam problem ze znalezieniem autorytatywnych informacji o zachowaniu w zduplikowanych polach ciągu zapytania HTTP GET, takich jak

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

aw szczególności czy zamówienie jest zachowane czy nie. Większość języków zorientowanych na sieć tworzy tablicę zawierającą zarówno foo, jak i bar skojarzone z kluczowym „polem”, ale chciałbym wiedzieć, czy istnieje autorytatywne stwierdzenie (np. W specyfikacji RFC) dotyczące tego punktu. RFC 3986 zawiera sekcję 3.4. Query, która odwołuje się do par klucz = wartość, ale nie powiedziano nic o tym, jak interpretować kolejność, zduplikowane pola i tak dalej. Ma to sens, ponieważ jest zależne od zaplecza, a nie w zakresie tego RFC ...

Chociaż faktycznie istnieje standard, chciałbym zobaczyć wiarygodne jego źródło, tak z ciekawości.

Nie ma specyfikacji na ten temat. Możesz robić, co chcesz.

Typowe podejścia obejmują: pierwszy-dany, ostatni-dany, tablica-wszystkiego, łańcuch-łączony-z-przecinkiem-wszystkiego.

Załóżmy, że surowe żądanie to:

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

Istnieją różne opcje tego, co request.query['tag']powinno dać, w zależności od języka lub struktury:

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

Mogę potwierdzić, że dla PHP (przynajmniej w wersji 4.4.4 i nowszych) działa to tak:

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

prowadzi do:

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

Ale

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

prowadzi do:

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

To zachowanie jest takie samo dla danych GET i POST.

Odpowiedź yfeldblum jest doskonała.

Tylko uwaga o piątym zachowaniu, które zauważyłem niedawno: w Windows Phone otwarcie aplikacji z uri ze zduplikowanym kluczem zapytania spowoduje NavigationFailed with:

System.ArgumentException: element z tym samym kluczem został już dodany.

Winowajcą jest System.Windows.Navigation.UriParsingHelper.InternalUriParseQueryStringToDictionary(Uri uri, Boolean decodeResults).

Więc system nawet nie pozwoli ci obsłużyć tego tak, jak chcesz, zabroni tego. Pozostaje Ci jedyne rozwiązanie pozwalające wybrać własny format (CSV, JSON, XML, ...) i uri-escape-it.

Większość (wszystkich?) Frameworków nie daje żadnych gwarancji, więc załóżmy, że zostaną zwrócone w losowej kolejności.

Zawsze wybieraj najbezpieczniejsze podejście.

Na przykład interfejs Java HttpServlet: ServletRequest.html # getParameterValues

Nawet metoda getParameterMap nie wspomina o kolejności parametrów (nie można również polegać na kolejności iteratora java.util.Map).

Zwykle zduplikowane wartości parametrów, takie jak

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

wynik w pojedynczym parametrze queryString, który jest tablicą:

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

Widziałem to zachowanie w ASP, ASP.NET i PHP4.

Miałem to samo pytanie. Piszę funkcję javascript do analizowania i stringify zapytań. Nie wiem, czy ciąg zapytania ma zduplikowane nazwy lub nazwę w nawiasach, na przykład x [] = 1 i x [] = 2, jest standardem, chociaż niektóre języki obsługują ten format.

Ale uważam, że Chrome i Firefox mają nową klasę o nazwie URLSeachParamsi obsługują tylko najprostszy format, jak name=value. Jeśli w ciągu zapytania znajdują się zduplikowane nazwy, getmetoda URLSearchParamszwraca tylko pierwszą.

Więc osobiście, być może najprostszy adres URL bez zduplikowanych nazw jest znacznie bezpieczniejszy na przyszłość.