web-dev-qa-db-fra.com

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

Je ne parviens pas à trouver des informations faisant autorité sur le comportement des champs en double de chaîne de requête HTTP GET, tels que 

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 à un "champ" clé, mais j'aimerais savoir s'il existe une déclaration faisant autorité (par exemple sur un RFC) à ce sujet. La RFC 3986 a une section 3.4. Query, qui fait référence à des 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, car cela dépend du backend, et non de la portée de cette RFC ...

Bien qu’il existe une norme de facto, je voudrais voir une source faisant autorité pour elle, juste par curiosité.

httpuri
118
Stefano Borini

Il Il n'y a pas de spécification sur ceci. Vous pouvez faire ce que vous aimez.

Les approches typiques incluent: le premier, le dernier, le tableau complet, la chaîne jointe à la 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 générer, en fonction de la langue ou du cadre:

request.query['tag'] => 'Ruby'
request.query['tag'] => 'Rails'
request.query['tag'] => ['Ruby', 'Rails']
request.query['tag'] => 'Ruby,Rails'
94
yfeldblum

Je peux confirmer que pour PHP (au moins dans la version 4.4.4 et ultérieure), cela fonctionne comme suit:

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.

14
SimonSimCity

la réponse de yfeldblum est parfaite.

Juste une note sur 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 en double entraîne le renvoi de NavigationFailed avec:

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

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

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

6
Cœur

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

Toujours prendre l'approche la plus sûre.

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

Même la méthode getParameterMap ne mentionne rien sur l'ordre des paramètres (l'ordre d'un itérateur Java.util.Map ne peut pas être invoqué.)

5
Photodeus

En général, les valeurs de paramètre en double telles que

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

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

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

J'ai vu ce comportement dans ASP, ASP.NET et PHP4.

4
3Dave

J'ai eu la même question. J'écris la fonction javascript pour analyser et stringifier les requêtes. Je ne sais pas si une chaîne de requête a des noms en double ou avec des crochets, tels que x [] = 1 et x [] = 2, est standard bien que certaines langues prennent en charge ces formats.

Mais je trouve que Chrome et Firefox ont une nouvelle classe nommée URLSeachParams et qu’ils ne prennent en charge que le format le plus simple, à savoir name=value. S'il existe des noms en double dans la chaîne de requête, la méthode get de URLSearchParams ne renvoie que la première.

Donc, personnellement, une URL simple et sans doublons de noms est bien plus sûre pour l’avenir.

0
LCB