medicina - Posición autoritativa de claves de consulta HTTP GET duplicadas

uri web

Question

Tengo problemas para encontrar información autorizada sobre el comportamiento con los campos duplicados de la cadena de consulta HTTP GET, como

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

y en particular si el orden se mantiene o no. La mayoría de los lenguajes orientados a web producen una matriz que contiene foo y barra asociados a un "campo" clave, pero me gustaría saber si existe una declaración autorizada (por ejemplo, en un RFC) sobre este punto. RFC 3986 tiene una sección 3.4. Query 3.4. Query , que se refiere a pares clave = valor, pero no se dice nada sobre cómo interpretar el orden y duplicar campos, etc. Esto tiene sentido, ya que depende del servidor y no del alcance de ese RFC ...

Aunque existe un estándar de facto, me gustaría ver una fuente autorizada para él, solo por curiosidad.

Answer 1

La mayoría (¿todos?) De los marcos no ofrecen garantías, así que supongamos que serán devueltos en orden aleatorio.

Siempre tome el enfoque más seguro.

Por ejemplo, java HttpServlet interface: ServletRequest.html#getParameterValues

Incluso el método getParameterMap omite cualquier mención sobre el orden de los parámetros (tampoco se puede confiar en el orden de un iterador java.util.Map).

Answer 2

La respuesta de yfeldblum es perfecta.

Solo una nota sobre un quinto comportamiento que noté recientemente: en Windows Phone , abrir una aplicación con un uri con una clave de consulta duplicada dará como resultado NavigationFailed con:

System.ArgumentException: un elemento con la misma clave ya se ha agregado.

El culpable es System.Windows.Navigation.UriParsingHelper.InternalUriParseQueryStringToDictionary(Uri uri, Boolean decodeResults) .

Entonces el sistema ni siquiera te dejará manejarlo de la manera que quieras, lo prohibirá. Te queda la única solución para elegir tu propio formato (CSV, JSON, XML, ...) y uri-escape-it.

Answer 3

No hay especificaciones sobre esto. Puedes hacer lo que quieras.

Los enfoques típicos incluyen: first-given, last-given, array-of-all, string-join-with-comma-of-all.

Supongamos que la solicitud sin procesar es:

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

Luego hay varias opciones para qué request.query[''tag''] debe ceder, dependiendo del idioma o el marco:

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

Answer 4

Puedo confirmar que para PHP (al menos en la versión 4.4.4 y posterior) funciona así:

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

resultados en:

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

Pero

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

resultados en:

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

Este comportamiento es el mismo para los datos GET y POST.

Answer 5

Típicamente, valores de parámetros duplicados como

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

dar como resultado un único parámetro queryString que es una matriz:

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

He visto este comportamiento en ASP, ASP.NET y PHP4.

Answer 6

Tenía la misma pregunta. Estoy escribiendo la función de Javascript para analizar y codificar las consultas. No sé si una cadena de consulta tiene nombres o nombres duplicados con corchetes, como x [] = 1 & x [] = 2, aunque algunos idiomas admiten este formato.

Pero me parece que Chrome y Firefox tienen una nueva Clase llamada URLSeachParams y solo admite el formato más simple como name=value . Si hay nombres duplicados en la cadena de consulta, el método get de URLSearchParams solo devuelve el primero.

Así que personalmente, quizás una URL de nombres duplicados y más simple sea mucho más segura para el futuro.