Cadena de consulta

Una cadena de consulta es una parte de un localizador uniforme de recursos (URL) que asigna valores a parámetros específicos. 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 documento HTML, al elegir la apariencia de una página o al saltar a posiciones en contenido multimedia.

Un servidor web puede gestionar una solicitud de Protocolo de transferencia de hipertexto (HTTP) leyendo un archivo de su sistema de archivos en función de la ruta URL o gestionando la solicitud mediante una lógica específica para el 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.

Una 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 de una página de este tipo, puede ejecutar un programa y pasar la cadena de consulta, que en este caso es name=ferret, sin modificaciones al programa. El signo de interrogación se utiliza como separador y no forma parte de la cadena de consulta. ^{[1] [2]}

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

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 contiene una cadena de consulta. HTML define tres formas en las que un agente de usuario puede generar la cadena de consulta:

• un formulario HTML a través del <form>...</form>elemento
• un mapa de imagen del lado del servidor a través del ismapatributo en el <img>elemento con una <img ismap>construcción
• una búsqueda indexada a través del <isindex>elemento ahora obsoleto

Uno de los usos originales era contener el contenido de un formulario HTML , también conocido como formulario web. En particular, cuando se envía un formulario que contiene los campos field1, field2, field3, el contenido de los campos se codifica como una cadena de consulta de la siguiente manera:

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

• La cadena de consulta se compone de una serie de pares de campo-valor.
• 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 ampersand , " &" ( el W3C ya no recomienda el uso de punto y coma " " , consulte a continuación).;

Si bien no existe un estándar definitivo, la mayoría de los marcos web permiten asociar múltiples valores con un solo campo (por ejemplo, field1=value1&field1=value2&field2=value3). ^{[4] [5]}

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 formulario.field=value

Esta convención es una recomendación del W3C . ^[3] En las recomendaciones de 1999, el W3C recomendó que todos los servidores web admitieran separadores de punto y coma además de separadores de ampersand ^[6] para permitir cadenas de consulta application/x-www-form-urlencoded en URL dentro de documentos HTML sin tener que usar ampersands de escape de entidad. Desde 2014, el W3C recomienda utilizar solo ampersand como separador de consultas. ^[7]

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. ^[8]

Antes de que se añadieran los formularios<isindex> a HTML, los navegadores representaban el elemento – como un control de entrada de texto de una sola línea. El texto introducido en este control se enviaba al servidor como una cadena de consulta que se sumaba a una solicitud GET para la URL base u otra URL especificada por el actionatributo. ^[9] Esto tenía como objetivo permitir que los servidores web utilizaran el texto proporcionado como criterio de consulta para poder devolver una lista de páginas coincidentes. ^[10]

Cuando se envía el texto ingresado al control de búsqueda indexado, 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 analizando el texto en palabras en los espacios.
• La serie está separada por el signo más , ' +'.

Aunque el <isindex>elemento está en desuso y la mayoría de los navegadores ya no lo admiten ni lo representan, aún 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 de porcentaje de URL del navegador (que hoy, con la desuso de la búsqueda indexada, es prácticamente 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 comandos si no contiene un signo igual , ' =' (según la sección 4.4 de CGI 1.1). Algunos scripts CGI aún dependen y utilizan este comportamiento histórico para las URL incrustadas en HTML.

Algunos caracteres no pueden formar parte de una URL (por ejemplo, el espacio) y otros tienen un significado especial en una URL: por ejemplo, el carácter #se puede utilizar para especificar 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 la codificación URL para solucionar este problema, mientras que los formularios HTML realizan algunas sustituciones adicionales en lugar de aplicar la codificación porcentual para todos esos caracteres. El ESPACIO se codifica como ' +' o " %20". ^[11]

HTML 5 especifica la siguiente transformación para enviar formularios HTML con el método "GET" a un servidor web. A continuación se presenta un breve resumen del algoritmo:

• Los caracteres que no se pueden convertir al conjunto de caracteres correcto se reemplazan con referencias de caracteres numéricos HTML ^[12]
• El ESPACIO se codifica 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 y cualquier carácter que no sea ASCII se codifica primero como UTF-8 (u otra codificación especificada).

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

La codificación del ESPACIO como ' +' y la selección de caracteres "tal cual" distinguen esta codificación de RFC 3986.

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

< formulario  acción = "/cgi-bin/test.cgi"  método = "obtener" >  < tipo de entrada  = "texto" nombre = "primero" /> < tipo de entrada = "texto" nombre = "segundo" /> < tipo de entrada = "enviar" /> </ formulario >         

y el usuario inserta las cadenas "este es un campo" y "¿ya estaba claro?" en los dos campos de texto y presiona el botón enviar, 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 es procesado en el servidor por un script CGI , el script normalmente puede recibir la cadena de consulta como una variable de entorno denominada .QUERY_STRING

Un programa que recibe una cadena de consulta puede ignorarla total o parcialmente. 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 ella, se almacena en los archivos de registro del servidor .

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

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

 < a  href = "foo.html" > ¡mira mi página! </ a >  < a  href = "bar.html" > la mía es mejor </ a >

se elige una cadena única, como la que e0a72cb2a2c7se muestra a continuación, y la página se modifica de la siguiente manera:

 < a  href = "foo.html?e0a72cb2a2c7" > ¡mira mi página! </ a >  < a  href = "bar.html?e0a72cb2a2c7" > la mía es mejor </ a >

La adición de la cadena de consulta no modifica 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 espera, 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 vistas 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) caminos independientes, se le asignarán dos cadenas de consulta diferentes, mientras que las cookies almacenadas serán las mismas.
3. El usuario puede desactivar las cookies, en cuyo caso el uso de cookies para el seguimiento no funcionará. Sin embargo, el uso de cadenas de consulta para el seguimiento debería funcionar en todas las situaciones.
4. El paso de diferentes cadenas de consulta por distintas visitas a la página provocará que las páginas nunca se muestren desde el caché del navegador (o proxy, si está presente), lo que aumenta la carga en el servidor web y ralentiza la experiencia del usuario.

Según la especificación HTTP :

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

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 habitual 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 mayores que los de la longitud de las URL. Por ejemplo, el límite de tamaño de POST, de forma predeterminada, es de 2 MB en IIS 4.0 y de 128 KB en IIS 5.0. El límite se puede configurar en Apache2 mediante la LimitRequestBodydirectiva , que especifica la cantidad de bytes desde 0 (es decir, ilimitado) hasta 2147483647 (2 GB) que se permiten en el cuerpo de una solicitud. ^[14]

• Fragmento de URI
• Normalización de URI
• URL (Localizador uniforme de recursos)
• 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 URI
• Parámetros UTM
• Balizas web