Posição autorizada de chaves de consulta HTTP GET duplicadas

Estou com problemas para encontrar informações autorizadas sobre o comportamento dos campos duplicados da sequência de consultas HTTP GET, como

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

e, em particular, se o pedido for mantido ou não. A maioria das linguagens orientadas à web produz uma matriz que contém foo e bar associados a um "campo" principal, mas eu gostaria de saber se existe uma declaração autorizada (por exemplo, em uma RFC) sobre esse ponto. O RFC 3986 possui uma seção 3.4. Query, que se refere aos pares chave = valor, mas nada é dito sobre como interpretar a ordem e os campos duplicados e assim por diante. Isso faz sentido, já que é dependente de back-end e não está no escopo dessa RFC ...

Embora exista um padrão de fato, eu gostaria de ver uma fonte autorizada para isso, apenas por curiosidade.

Não há especificações sobre isso. Você pode fazer o que quiser.

As abordagens típicas incluem: primeiro, último, conjunto de todos, junção de cadeia com vírgula de todos.

Suponha que a solicitação bruta seja:

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

Existem várias opções para o que request.query['tag']deve render, dependendo do idioma ou da estrutura:

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

Posso confirmar que, para PHP (pelo menos na versão 4.4.4 e mais recente), funciona assim:

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

resulta em:

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

Mas

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

resulta em:

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

Esse comportamento é o mesmo para dados GET e POST.

A resposta de yfeldblum é perfeita.

Apenas uma observação sobre um quinto comportamento que notei recentemente: no Windows Phone , abrir um aplicativo com uma interface de usuário com uma chave de consulta duplicada resultará em NavigationFailed with:

System.ArgumentException: um item com a mesma chave já havia sido adicionado.

O culpado é System.Windows.Navigation.UriParsingHelper.InternalUriParseQueryStringToDictionary(Uri uri, Boolean decodeResults).

Portanto, o sistema nem permitirá que você lide com isso da maneira que quiser, o proibirá. Você tem a única solução para escolher seu próprio formato (CSV, JSON, XML, ...) e uri-escape-it.

A maioria (todas?) Das estruturas não oferece garantias, portanto, assuma que elas serão retornadas em ordem aleatória.

Sempre adote a abordagem mais segura.

Por exemplo, interface Java HttpServlet: ServletRequest.html # getParameterValues

Até o método getParameterMap não menciona a ordem dos parâmetros (a ordem de um iterador java.util.Map também não pode ser invocada.)

Normalmente, valores de parâmetros duplicados, como

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

resultam em um único parâmetro queryString que é uma matriz:

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

Eu já vi esse comportamento no ASP, ASP.NET e PHP4.

Eu tive a mesma pergunta. Estou escrevendo a função javascript para analisar e modificar consultas. Não sei se uma string de consulta possui nomes duplicados ou entre colchetes, como x [] = 1 & x [] = 2, é padrão, embora alguns idiomas suportem esse formato.

Mas acho que o Chrome e o Firefox têm uma nova classe denominada URLSeachParamse suporta apenas o formato mais simples como name=value. Se houver nomes duplicados na string de consulta, o getmétodo deURLSearchParams retornará apenas o primeiro.

Então, pessoalmente, talvez um URL mais simples e sem nomes duplicados seja muito mais seguro para o futuro.