Position faisant autorité des clés de requête HTTP GET en double

J’ai du mal à trouver des informations faisant autorité sur le comportement avec les champs de duplication de chaîne de requête HTTP GET, comme

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

et en particulier si la commande est conservée ou non. La plupart des langages orientés Web produisent un tableau contenant à la fois foo et bar associés à une “zone” de clé, mais j’aimerais savoir si une déclaration faisant autorité (par exemple sur une RFC) existe à ce sujet. La RFC 3986 a une section 3.4. Query 3.4. Query , qui fait référence aux paires clé = valeur, mais rien n’est dit sur la façon d’interpréter les champs d’ordre et de duplication, etc. Cela a du sens, puisque cela dépend du backend, et non de la scope de cette RFC …

Bien qu’il existe une norme de facto, j’aimerais voir une source faisant autorité, juste par curiosité.

Il n’y a pas de spécifications à ce sujet. Vous pouvez faire ce que vous voulez.

Les approches typiques incluent: premier-donné, dernier-donné, tableau-de-tous, chaîne-jointure-avec-virgule.

Supposons que la demande brute est:

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

Ensuite, il existe différentes options pour ce que request.query['tag'] doit donner, en fonction de la langue ou du framework:

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

Je peux confirmer que pour PHP (au moins dans la version 4.4.4 et plus récente), cela fonctionne comme ceci:

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

résulte en:

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

Mais

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

résulte en:

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

Ce comportement est identique pour les données GET et POST.

La plupart (tous?) Des frameworks n’offrent aucune garantie, donc supposons qu’ils seront renvoyés dans un ordre aléatoire.

Prenez toujours l’approche la plus sûre.

Par exemple, l’interface Java HttpServlet: ServletRequest.html # getParameterValues

Même la méthode getParameterMap exclut toute mention de l’ordre des parameters (l’ordre de l’iterator java.util.Map ne peut pas non plus être utilisé).

La réponse de Yfeldblum est parfaite.

Juste une note à propos d’un cinquième comportement que j’ai remarqué récemment: sur Windows Phone , l’ouverture d’une application avec un uri avec une clé de requête dupliquée entraînera NavigationFailed avec:

System.ArgumentException: Un élément avec la même clé a déjà été ajouté.

Le coupable est System.Windows.Navigation.UriParsingHelper.InternalUriParseQuerySsortingngToDictionary(Uri uri, Boolean decodeResults) .

Ainsi, le système ne vous laissera même pas le gérer comme vous le souhaitez, cela l’interdira. Il ne rest que la seule solution pour choisir votre propre format (CSV, JSON, XML, …) et uri-escape-it.

En règle générale, les valeurs de parameters en double, telles que

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

résulte en un seul paramètre querySsortingng qui est un tableau:

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

J’ai vu ce comportement en ASP, ASP.NET et PHP4.

J’ai eu la même question. J’écris la fonction JavaScript pour parsingr et limiter les requêtes. Je ne sais pas si une chaîne de requête a des noms en double ou un nom avec des crochets, tels que x [] = 1 & x [] = 2, est standard bien que certains langages supportent ces formats.

Mais je trouve que Chrome et Firefox ont une nouvelle classe nommée URLSeachParams et elle ne supporte que le format le plus simple comme name=value . S’il existe des noms en double dans la chaîne de requête, la méthode get de URLSearchParams uniquement le premier.

Donc, personnellement, peut-être un nom simple et sans doublon, l’url est beaucoup plus sûr pour l’avenir.