String de consulta

Uma barra de endereço no Google Chrome mostrando um URL com a string de consulta title=Query_string&action=edit.

Uma string de consulta é uma parte de um localizador uniforme de recursos (URL) que atribui valores a parâmetros especificados. Uma string de consulta geralmente inclui campos adicionados a um URL base por um navegador da Web ou outro aplicativo cliente, por exemplo, como parte de um formulário HTML. ^[1]

Um servidor da web pode lidar com uma solicitação de protocolo de transferência de hipertexto (HTTP) lendo um arquivo de seu sistema de arquivos com base no caminho da URL ou manipulando a solicitação usando uma lógica específica para o tipo de recurso. Nos casos em que uma lógica especial é chamada, a string de consulta estará disponível para essa lógica para uso em seu processamento, junto com o componente de caminho da URL.

Estrutura

O URL típico que contém uma string de consulta é o seguinte:

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

Quando um servidor recebe uma solicitação para tal página, ele pode executar um programa, passando a string de consulta, que neste caso é name=ferret, inalterada para o programa. O ponto de interrogação é usado como separador e não faz parte da string de consulta. ^{[2] [3]} *

As estruturas da Web podem fornecer métodos para analisar vários parâmetros na string de consulta, separados por algum delimitador. ^[4] No exemplo de URL abaixo, vários parâmetros de consulta são separados pelo E comercial , " &":

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

A estrutura exata da string de consulta não é padronizada. Os métodos usados ​​para analisar a string de consulta podem ser diferentes entre os sites.

Um link em uma página da web pode ter um URL que contém uma string de consulta. HTML define três maneiras pelas quais um agente de usuário pode gerar a string de consulta:

• um formulário HTML por meio do <form>...</form>elemento
• um mapa de imagem do lado do servidor por meio do ismapatributo no <img>elemento com uma <img ismap>construção
• uma pesquisa indexada por meio do <isindex>elemento agora obsoleto

Formulários web

Um dos usos originais era conter o conteúdo de um formulário HTML , também conhecido como formulário da web. Em particular, quando um formulário que contém os campos field1, field2, field3é apresentado, o conteúdo dos campos é codificada como uma sequência de consulta como se segue:

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

• A string de consulta é composta por uma série de pares de valores de campo.
• Dentro de cada par, o nome do campo e o valor são separados por um sinal de igual , " =".
• A série de pares é separada pelo "e " comercial , " &" (ou ponto e vírgula , " ;" para URLs incorporados em HTML e não gerados por a <form>...</form>. Veja abaixo).

Embora não haja um padrão definitivo, a maioria das estruturas da web permite que vários valores sejam associados a um único campo (por exemplo field1=value1&field1=value2&field2=value3). ^{[5] [6]}

Para cada campo do formulário, a string de consulta contém um par . Os formulários da Web podem incluir campos que não são visíveis ao usuário; esses campos são incluídos na string de consulta quando o formulário é enviado. field=value

Esta convenção é uma recomendação do W3C . ^{[4] O} W3C recomenda que todos os servidores web suportem separadores de ponto-e-vírgula além dos separadores e comercial ^[7] para permitir strings de consulta codificadas por application / x-www-form-url em URLs dentro de documentos HTML sem ter que a entidade escape de e comercial.

O conteúdo do formulário só é codificado na string de consulta do URL quando o método de envio do formulário é GET . A mesma codificação é usada por padrão quando o método de envio é POST , mas o resultado é enviado como o corpo da solicitação HTTP em vez de ser incluído em um URL modificado. ^[1]

Busca indexada

Antes de os formulários serem adicionados ao HTML, os navegadores renderizavam o <isindex>elemento como um controle de entrada de texto de linha única. O texto inserido nesse controle foi enviado ao servidor como uma adição de string de consulta a uma solicitação GET para a URL base ou outra URL especificada pelo actionatributo. ^[8] O objetivo era permitir que os servidores web usassem o texto fornecido como critério de consulta para que pudessem retornar uma lista de páginas correspondentes. ^[9]

Quando a entrada de texto no controle de pesquisa indexado é enviada, ela é codificada como uma string de consulta da seguinte maneira:

argument1+argument2+argument3...

• A string de consulta é composta por uma série de argumentos, analisando o texto em palavras nos espaços.
• A série é separada pelo sinal de mais , ' +'.

Embora o <isindex>elemento esteja obsoleto e a maioria dos navegadores não o suporte ou renderize mais, ainda existem alguns vestígios de pesquisa indexada. Por exemplo, esta é a fonte do tratamento especial do sinal de mais , ' +' dentro da codificação percentual da URL do navegador (que hoje, com a descontinuação da pesquisa indexada, é quase redundante com %20). Além disso, alguns servidores web que suportam CGI (por exemplo, Apache ) processarão a string de consulta em argumentos de linha de comando se ela não contiver um sinal de igual , ' =' (de acordo com a seção 4.4 de CGI 1.1). Alguns scripts CGI ainda dependem e usam esse comportamento histórico para URLs embutidos em HTML.

Codificação de URL

Alguns caracteres não podem fazer parte de um URL (por exemplo, o espaço) e alguns outros caracteres têm um significado especial em um URL: por exemplo, o caractere #pode ser usado para especificar uma subseção (ou fragmento ) de um documento. Em formulários HTML, o caractere =é usado para separar um nome de um valor. A sintaxe genérica de URI usa codificação de URL para lidar com esse problema, enquanto os formulários HTML fazem algumas substituições adicionais em vez de aplicar codificação de porcentagem para todos esses caracteres. SPACE é codificado como ' +' ou " %20". ^[10]

HTML 5 especifica a seguinte transformação para enviar formulários HTML com o método "GET" para um servidor da web. ^[1] O seguinte é um breve resumo do algoritmo:

• Os caracteres que não podem ser convertidos para o conjunto de caracteres correto são substituídos por referências de caracteres numéricos HTML ^[11]
• SPACE é codificado como ' +' ou ' %20'
• Letras ( A- Ze a- z), números ( 0- 9) e os caracteres ' ~', ' -', ' .' e ' _' são deixados como estão
• + é codificado por% 2B
• Todos os outros caracteres são codificados como uma representação %HH hexadecimal com quaisquer caracteres não ASCII codificados primeiro como UTF-8 (ou outra codificação especificada)

O octeto correspondente ao til (" ~") é permitido em strings de consulta pelo RFC3986, mas precisa ser codificado por cento em formulários HTML para " %7E".

A codificação de SPACE como ' +' e a seleção de caracteres "no estado em que se encontram" distinguem essa codificação da RFC 3986.

Exemplo

Se um formulário for incorporado em uma página HTML da seguinte maneira:

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

e o usuário insere as strings “isto é um campo” e “estava claro (já)?” nos dois campos de texto e pressiona o botão Enviar, o programa test.cgi(o programa especificado pelo action atributo do form elemento no exemplo acima) irá receber a seguinte string de consulta: first=this+is+a+field&second=was+it+clear+%28already%29%3F.

Se o formulário for processado no servidor por um script CGI , o script pode normalmente receber a string de consulta como uma variável de ambiente chamada . QUERY_STRING

Rastreamento

Um programa que recebe uma string de consulta pode ignorar parte ou tudo isso. Se o URL solicitado corresponder a um arquivo e não a um programa, toda a string de consulta será ignorada. No entanto, independentemente de a string de consulta ser usada ou não, todo o URL, incluindo ele, é armazenado nos arquivos de log do servidor .

Esses fatos permitem que cadeias de caracteres de consulta sejam usadas para rastrear usuários de maneira semelhante à fornecida pelos cookies HTTP . Para que isso funcione, cada vez que o usuário baixa uma página, um identificador exclusivo deve ser escolhido e adicionado como uma string de consulta aos URLs de todos os links que a página contém. Assim que o usuário segue um desses links, a URL correspondente é solicitada ao servidor. Desta forma, o download desta página fica vinculado à anterior.

Por exemplo, quando uma página da web contendo o seguinte é solicitada:

 < A  href = "foo.html" > ver a minha página! </ A > 
 < a  href = "bar.html" > meu é melhor </ a >

uma string única, como e0a72cb2a2c7é escolhida, e a página é modificada da seguinte maneira:

 < A  href = "foo.html? E0a72cb2a2c7" > ver a minha página! </ A > 
 < a  href = "bar.html? E0a72cb2a2c7" > meu é melhor </ a >

A adição da string de consulta não altera a maneira como a página é mostrada ao usuário. Quando o usuário segue, por exemplo, o primeiro link, o navegador solicita a página foo.html?e0a72cb2a2c7ao servidor, que ignora o que segue ?e envia a página foo.htmlconforme o esperado, adicionando também a string de consulta aos seus links.

Dessa forma, qualquer solicitação de página subsequente deste usuário carregará a mesma string de consulta e0a72cb2a2c7, permitindo estabelecer que todas essas páginas foram visualizadas pelo mesmo usuário. Strings de consulta são frequentemente usadas em associação com web beacons .

As principais diferenças entre as strings de consulta usadas para rastreamento e cookies HTTP são:

1. As strings de consulta fazem parte da URL e, portanto, são incluídas se o usuário salvar ou enviar a URL para outro usuário; os cookies podem ser mantidos nas sessões de navegação, mas não são salvos ou enviados com o URL.
2. Se o usuário chegar ao mesmo servidor web por dois (ou mais) caminhos independentes, serão atribuídos dois strings de consulta diferentes, enquanto os cookies armazenados são os mesmos.
3. O usuário pode desabilitar os cookies, caso em que o uso de cookies para rastreamento não funciona. No entanto, o uso de strings de consulta para rastreamento deve funcionar em todas as situações.
4. Sequências de caracteres de consulta diferentes passadas por diferentes visitas à página significarão que as páginas nunca são servidas a partir do cache do navegador (ou proxy, se houver), aumentando assim a carga no servidor da web e tornando mais lenta a experiência do usuário.

Compatibilidade questões

De acordo com a especificação HTTP :

Várias limitações ad hoc no comprimento da linha de solicitação são encontradas na prática. É RECOMENDADO que todos os remetentes e destinatários HTTP suportem, no mínimo, comprimentos de linha de solicitação de 8.000 octetos. ^[12]

Se o URL for muito longo, o servidor da web falhará com o código de status HTTP 414 Request-URI Too Long .

A solução alternativa comum para esses problemas é usar POST em vez de GET e armazenar os parâmetros no corpo da solicitação. Os limites de comprimento em corpos de solicitação são normalmente muito maiores do que aqueles em comprimento de URL. Por exemplo, o limite do tamanho do POST, por padrão, é 2 MB no IIS 4.0 e 128 KB no IIS 5.0. O limite é configurável no Apache2 usando a LimitRequestBodydiretiva, que especifica o número de bytes de 0 (significando ilimitado) a 2147483647 (2 GB) que são permitidos em um corpo de solicitação. ^[13]

Veja também

• URL limpo
• Identificador de clique
• Interface de gateway comum (CGI)
• Cookie HTTP
• Protocolo de transferência de hipertexto (HTTP)
• URLs semânticos
• Esquema URI
• Parâmetros UTM
• Beacon da web

Referências

Ligações externas

• RFC 3986