De Wikipedia, la enciclopedia libre
Ir a navegaciónSaltar a buscar
Una barra de direcciones en Google Chrome que muestra una URL con la cadena de consulta title=Query_string&action=edit.

Una cadena de consulta es parte de un localizador de recursos uniforme (URL) que asigna valores a parámetros especificados. Una cadena de consulta generalmente incluye campos agregados a una URL base por un navegador web u otra aplicación cliente, por ejemplo, como parte de un formulario HTML. [1]

Un servidor web puede manejar una solicitud de Protocolo de transferencia de hipertexto (HTTP), ya sea leyendo un archivo de su sistema de archivos en función de la ruta URL o manejando la solicitud utilizando la lógica específica del tipo de recurso. En los casos en los que se invoca una lógica especial, la cadena de consulta estará disponible para que esa lógica la utilice en su procesamiento, junto con el componente de ruta de la URL.

Estructura

La URL típica que contiene una cadena de consulta es la siguiente:

https://example.com/over/there?name=ferret

Cuando un servidor recibe una solicitud para dicha página, puede ejecutar un programa, pasando la cadena de consulta, que en este caso no se name=ferretmodifica al programa. El signo de interrogación se utiliza como separador y no forma parte de la cadena de consulta. [2] [3]

Los marcos web pueden proporcionar métodos para analizar múltiples parámetros en la cadena de consulta, separados por algún delimitador. [4] En la URL de ejemplo a continuación, varios parámetros de consulta están separados por el signo " &":

https://example.com/path/to/page?name=ferret&color=purple

La estructura exacta de la cadena de consulta no está estandarizada. Los métodos utilizados para analizar la cadena de consulta pueden diferir entre sitios web.

Un enlace en una página web puede tener una URL que contenga una cadena de consulta. HTML define tres formas en que un agente de usuario puede generar la cadena de consulta:

Formularios web

Uno de los usos originales fue contener el contenido de un formulario HTML , también conocido como formulario web. En particular, cuando una forma que contiene los campos field1, field2, field3se presenta, el contenido de los campos se codifica como una cadena de consulta como sigue:

field1=value1&field2=value2&field3=value3...

  • La cadena de consulta se compone de una serie de pares de valor de campo.
  • Dentro de cada par, el nombre del campo y el valor están separados por un signo igual , " =".
  • La serie de pares está separada por el signo comercial , " &" (o punto y coma , " ;" para las URL incrustadas en HTML y no generadas por a <form>...</form>. Ver más abajo).

Si bien no existe un estándar definitivo, la mayoría de los marcos web permiten asociar varios valores con un solo campo (p field1=value1&field1=value2&field2=value3. Ej .). [5] [6]

Para cada campo del formulario, la cadena de consulta contiene un par . Los formularios web pueden incluir campos que no son visibles para el usuario; estos campos se incluyen en la cadena de consulta cuando se envía el formulariofield=value

Esta convención es una recomendación del W3C . [4] W3C recomienda que todos los servidores web admitan separadores de punto y coma además de separadores de y comercial [7] para permitir cadenas de consulta con codificación de aplicación / x-www-form-urlencoded en URL dentro de documentos HTML sin tener que escapar de la entidad.

El contenido del formulario solo se codifica en la cadena de consulta de la URL cuando el método de envío del formulario es GET . La misma codificación se utiliza de forma predeterminada cuando el método de envío es POST , pero el resultado se envía como el cuerpo de la solicitud HTTP en lugar de incluirse en una URL modificada. [1]

Búsqueda indexada

Antes de que se añadieran formularios a HTML, los navegadores representaban el <isindex>elemento como un control de entrada de texto de una sola línea. El texto ingresado en este control se envió al servidor como una cadena de consulta adicional a una solicitud GET para la URL base u otra URL especificada por el actionatributo. [8] Esto estaba destinado a permitir que los servidores web utilizaran el texto proporcionado como criterio de consulta para que pudieran devolver una lista de páginas coincidentes. [9]

Cuando se envía la entrada de texto en el control de búsqueda indexada, se codifica como una cadena de consulta de la siguiente manera:

argument1+argument2+argument3...

  • La cadena de consulta se compone de una serie de argumentos al analizar el texto en palabras en los espacios.
  • La serie está separada por el signo más ' +'.

Aunque el <isindex>elemento está obsoleto y la mayoría de los navegadores ya no lo admiten ni lo procesan, todavía existen algunos vestigios de búsqueda indexada. Por ejemplo, esta es la fuente del manejo especial del signo más , ' +' dentro de la codificación porcentual de la URL del navegador (que hoy, con la desaprobación de la búsqueda indexada, es casi redundante con %20). Además, algunos servidores web que admiten CGI (por ejemplo, Apache ) procesarán la cadena de consulta en argumentos de línea de comando si no contiene un signo igual ' =' (según la sección 4.4 de CGI 1.1). Algunos scripts CGI todavía dependen y utilizan este comportamiento histórico para URL incrustadas en HTML.

Codificación de URL

Algunos caracteres no pueden formar parte de una URL (por ejemplo, el espacio) y algunos otros caracteres tienen un significado especial en una URL: por ejemplo, el carácter #se puede utilizar para especificar más una subsección (o fragmento ) de un documento. En los formularios HTML, el carácter =se utiliza para separar un nombre de un valor. La sintaxis genérica de URI utiliza codificación URL para solucionar este problema, mientras que los formularios HTML realizan algunas sustituciones adicionales en lugar de aplicar codificación porcentual para todos esos caracteres. SPACE está codificado como ' +' o " %20". [10]

HTML 5 especifica la siguiente transformación para enviar formularios HTML con el método "GET" a un servidor web. [1] El siguiente es un breve resumen del algoritmo:

  • Los caracteres que no se pueden convertir al juego de caracteres correcto se reemplazan con referencias de caracteres numéricos HTML [11]
  • SPACE está codificado como +"o %20"
  • Las letras ( A- Zy a- z), los números ( 0- 9) y los caracteres ' ~', ' -', ' .' y ' _' se dejan como están
  • + está codificado por% 2B
  • Todos los demás caracteres se codifican como una representación %HH hexadecimal con cualquier carácter no ASCII codificado primero como UTF-8 (u otra codificación especificada)

El octeto correspondiente a la tilde (" ~") está permitido en las cadenas de consulta por RFC3986 pero se requiere que esté codificado en porcentaje en formularios HTML a " %7E".

La codificación de SPACE como ' +' y la selección de caracteres "tal cual" distingue esta codificación de RFC 3986.

Ejemplo

Si un formulario está incrustado en una página HTML de la siguiente manera:

< form  action = "/cgi-bin/test.cgi"  method = "get" >  < input  type = "text"  name = "first"  />  < input  type = "text"  name = "second"  />  < input  type = "submit"  /> </ form >

y el usuario inserta las cadenas "este es un campo" y "¿estaba claro (ya)?" en los dos campos de texto y presiona el botón de envío, el programa test.cgi(el programa especificado por el action atributo del form elemento en el ejemplo anterior) recibirá la siguiente cadena de consulta: first=this+is+a+field&second=was+it+clear+%28already%29%3F.

Si el formulario se procesa en el servidor mediante un script CGI , el script normalmente puede recibir la cadena de consulta como una variable de entorno nombrada .QUERY_STRING

Seguimiento

Un programa que recibe una cadena de consulta puede ignorarla en parte o en su totalidad. Si la URL solicitada corresponde a un archivo y no a un programa, se ignora toda la cadena de consulta. Sin embargo, independientemente de si se utiliza o no la cadena de consulta, la URL completa, incluida la URL, se almacena en los archivos de registro del servidor .

Estos hechos permiten que las cadenas de consulta se utilicen para rastrear a los usuarios de una manera similar a la proporcionada por las cookies HTTP . Para que esto funcione, cada vez que el usuario descarga una página, se debe elegir un identificador único y agregarlo como una cadena de consulta a las URL de todos los enlaces que contiene la página. Tan pronto como el usuario sigue uno de estos enlaces, se solicita al servidor la URL correspondiente. De esta forma, la descarga de esta página se vincula con la anterior.

Por ejemplo, cuando se solicita una página web que contiene lo siguiente:

 < Un  href = "foo.html" > ver a mi página! </ Una >  < un  href = "bar.html" > mina es mejor </ una >

una cadena única, como e0a72cb2a2c7se elige, y la página se modifica de la siguiente manera:

 < Un  href = "foo.html? E0a72cb2a2c7" > ver a mi página! </ A >  < un  href = "bar.html? E0a72cb2a2c7" > la mía es mejor </ a >

La adición de la cadena de consulta no cambia la forma en que se muestra la página al usuario. Cuando el usuario sigue, por ejemplo, el primer enlace, el navegador solicita la página foo.html?e0a72cb2a2c7al servidor, que ignora lo que sigue ?y envía la página foo.htmlcomo se esperaba, añadiendo también la cadena de consulta a sus enlaces.

De esta manera, cualquier solicitud de página posterior de este usuario llevará la misma cadena de consulta e0a72cb2a2c7, lo que permite establecer que todas estas páginas han sido visitadas por el mismo usuario. Las cadenas de consulta se utilizan a menudo en asociación con balizas web .

Las principales diferencias entre las cadenas de consulta utilizadas para el seguimiento y las cookies HTTP son las siguientes:

  1. Las cadenas de consulta forman parte de la URL y, por lo tanto, se incluyen si el usuario guarda o envía la URL a otro usuario; Las cookies se pueden mantener durante las sesiones de navegación, pero no se guardan ni se envían con la URL.
  2. Si el usuario llega al mismo servidor web por dos (o más) rutas independientes, se le asignarán dos cadenas de consulta diferentes, mientras que las cookies almacenadas son las mismas.
  3. El usuario puede deshabilitar las cookies, en cuyo caso el uso de cookies para el seguimiento no funciona. Sin embargo, el uso de cadenas de consulta para el seguimiento debería funcionar en todas las situaciones.
  4. Las diferentes cadenas de consulta pasadas por diferentes visitas a la página significarán que las páginas nunca se sirven desde la caché del navegador (o proxy, si está presente), lo que aumenta la carga en el servidor web y ralentiza la experiencia del usuario.

Problemas de compatibilidad

Según la especificación HTTP :

En la práctica, se encuentran varias limitaciones ad hoc sobre la longitud de la línea de solicitud. Se RECOMIENDA que todos los remitentes y destinatarios HTTP admitan, como mínimo, longitudes de línea de solicitud de 8000 octetos. [12]

Si la URL es demasiado larga, el servidor web falla con el código de estado HTTP 414 Request-URI Too Long .

La solución común para estos problemas es utilizar POST en lugar de GET y almacenar los parámetros en el cuerpo de la solicitud. Los límites de longitud de los cuerpos de las solicitudes suelen ser mucho más altos que los de la longitud de la URL. Por ejemplo, el límite de tamaño de POST, de forma predeterminada, es de 2 MB en IIS 4.0 y 128 KB en IIS 5.0. El límite se puede configurar en Apache2 mediante la LimitRequestBodydirectiva, que especifica el número de bytes desde 0 (es decir, ilimitado) hasta 2147483647 (2 GB) que se permiten en el cuerpo de una solicitud. [13]

Ver también

  • URL limpia
  • Identificador de clic
  • Interfaz de puerta de enlace común (CGI)
  • Cookie HTTP
  • Protocolo de transferencia de hipertexto (HTTP)
  • URL semánticas
  • Esquema de URI
  • Parámetros UTM
  • Baliza web

Referencias

  1. ^ a b c [1] , HTML5.2, recomendación del W3C, 14 de diciembre de 2017
  2. ^ T. Berners-Lee; R. Fielding; L. Masinter (enero de 2005). "RFC 3986" . "Componentes de sintaxis" (sección 3).
  3. ^ T. Berners-Lee; R. Fielding; L. Masinter (enero de 2005). "RFC 3986" . "Consulta" (sección 3.4).
  4. ^ a b Formularios en documentos HTML . W3.org. Consultado el 8 de septiembre de 2013.
  5. ^ "ServletRequest (Java EE 6)" . docs.oracle.com . 2011-02-10 . Consultado el 8 de septiembre de 2013 .
  6. ^ "uri - Posición autorizada de claves de consulta HTTP GET duplicadas" . Desbordamiento de pila . 2013-06-09 . Consultado el 8 de septiembre de 2013 .
  7. ^ Notas de rendimiento, implementación y diseño . W3.org. Consultado el 8 de septiembre de 2013.
  8. ^ "<isindex>" . HTML (lenguaje de marcado de hipertexto) .
  9. ^ "HTML / Elementos / isindex" . Wiki del W3C .
  10. ^ "Referencia de codificación de URL HTML" . W3Schools . Consultado el 1 de mayo de 2013 .
  11. ^ El algoritmo de codificación application / x-www-form-urlencoded , HTML5.2, recomendación del W3C, 14 de diciembre de 2017
  12. ^ Sintaxis y enrutamiento de mensajes HTTP / 1.1 . ietf.org. Consultado el 31 de julio de 2014.
  13. ^ core - Servidor HTTP Apache . Httpd.apache.org. Consultado el 8 de septiembre de 2013.

Enlaces externos

  • RFC 3986