Analisar query string

Um query string pode trazer o mesmo nome várias vezes, e `etiqueta=a&etiqueta=b` é a forma comum de uma seleção múltipla. Quem carrega isso num dicionário perde tudo menos o último valor — uma perda de dados que nenhum aviso sinaliza.

Aqui cada ocorrência tem a linha dela. Isso importa mais do que soa, porque é justamente nas repetições que está o conteúdo de um filtro, de uma seleção de categorias ou de uma lista de identificadores. Se uma seleção múltipla chega pela metade no seu backend, o motivo quase sempre está aqui.

O PHP quer `etiqueta[]=a&etiqueta[]=b` e monta um array a partir dos colchetes. O Rails interpreta os colchetes de outra maneira e ainda aceita `etiqueta[chave]=` para montar um objeto. O Express tem mais de um modo, escolhido por configuração, e o padrão dele muda entre versões.

Nada disso está na especificação: um query string é texto, e a estrutura é invenção de cada biblioteca. A consequência é que uma URL montada por um front-end pode ser lida corretamente por um serviço e pela metade por outro, sem erro nenhum. Ver os pares crus aqui é o jeito mais rápido de descobrir de que lado está a divergência.

A entrada não precisa ser um endereço inteiro. Um query string com a interrogação inicial ou sem ela funciona igual a uma URL completa, da qual então a query é extraída — o que é cômodo, porque o que se copia de uma exportação de estatística ou de um log raramente é a linha completa.

O reconhecimento é feito pela presença de uma interrogação ou de um sinal de igual. Uma entrada sem nenhum dos dois não é um query string e sim texto comum, e não é tratada como tal — uma regra que soa óbvia e sem a qual uma URL inteira seria lida como um único nome de parâmetro.

Num query string, `+` significa tradicionalmente espaço. Vem do `application/x-www-form-urlencoded`, o formato com que os formulários HTML enviam, e é anterior à especificação atual de URL; sobreviveu porque os formulários continuam usando.

A consequência é uma armadilha: um sinal de mais de verdade dentro de um valor precisa ser escrito `%2B` ou ele some. Atinge sobretudo os telefones em formato internacional e os e-mails com subendereço — um `[email protected]` vira, na leitura, `ana [email protected]`, e a entrega falha num ponto para onde ninguém olha.

Um destino de redirecionamento como parâmetro é o caso mais comum de codificação aninhada: o valor de `proximo` é ele mesmo uma URL cujas barras e interrogações precisam estar escapadas para não desmontar o endereço de fora. Ao decodificar, ele volta a ser um endereço legível.

Aqui também dá para ver se alguém codificou duas vezes: se no valor decodificado ainda há um `%2F`, a entrada tinha passado duas vezes por um codificador. E quem recebe um redirecionamento assim deveria conferir o destino contra uma lista de hosts permitidos — os redirecionamentos abertos nascem exatamente neste ponto.

Para o servidor, `?a=1&b=2` e `?b=2&a=1` costumam significar a mesma coisa. Para tudo o que use a URL como chave, não: um cache, uma CDN e um contador de estatística tratam as duas como endereços diferentes, e a mesma página passa a ter duas entradas.

Com assinatura é pior, porque ali a ordem é parte do que vai virar hash. Um cliente que monta os parâmetros em ordem diferente da esperada gera uma assinatura diferente e recebe um erro sobre credencial, que não tem nada a ver. Manter a ordem estável, normalmente em ordem alfabética, é o hábito que evita os dois problemas.

Por padrão os valores são decodificados, que é o sentido da página. O botão para a forma crua não é enfeite: se uma assinatura é calculada sobre o query string, o que conta é a escrita codificada exata, e uma diferença entre `%20` e `+` decide entre aceitar e recusar.

Ela é igualmente útil para caçar dupla codificação. Um `%2520` no valor cru é a prova inequívoca de que em algum ponto da esteira um valor já codificado foi codificado de novo; no resultado decodificado disso sobra só um `%20` suspeito.

`utm_source`, `utm_medium`, `utm_campaign`, `utm_term` e `utm_content` vêm do Urchin, a ferramenta que deu origem ao Google Analytics — daí o nome. Eles não fazem nada no servidor: são texto que um script de medição lê no navegador.

Como não fazem nada, podem ser removidos sem consequência ao repassar um link, se você não quiser misturar a estatística de quem te mandou com a sua. E, como viajam no endereço, acabam em histórico, em link compartilhado e em favorito — a razão de alguns links de newsletter serem absurdamente longos.

Os endereços acabam no log do servidor, no histórico do navegador, no cabeçalho de referrer do clique seguinte e muitas vezes no log de um proxy pelo caminho. Uma senha, uma chave de sessão ou um token num parâmetro está, portanto, guardado em pelo menos quatro lugares em que ninguém pensou.

Para os links de confirmação e de redefinição, onde não há como evitar, a regra é: validade curta, uso único, e retirar da barra de endereço assim que a página abrir. Se aqui você vir um valor com cara de segredo, esse é o achado — e não o fato de ter dado para decodificar.

Um `?debug` sem valor, um `?a=` com valor vazio e um parâmetro ausente são três coisas diferentes, e os frameworks tratam de formas diferentes: às vezes como string vazia, às vezes como `true`, às vezes como inexistente. Aqui eles são mostrados exatamente como estão na string.

Isso é mais relevante do que parece. Uma chave que é passada só como nome chega em algumas linguagens como valor vazio e ali é avaliada como falso — o parâmetro está posto, a função não é ativada, e em nenhum log consta nada de chamativo.

Um query string não tem limite de número de parâmetros na especificação, e as implementações têm. O PHP, por padrão, para de aceitar depois de mil pares e descarta o resto sem erro; outros ambientes têm tetos parecidos, quase sempre configuráveis e quase nunca configurados.

Esses limites não foram inventados por capricho: eles vieram de ataques em que milhares de parâmetros construídos de propósito faziam a tabela de dispersão do servidor degenerar e consumir CPU. A consequência para quem depura é direta: se um formulário muito grande chega incompleto e nenhum log reclama, contar os parâmetros aqui costuma explicar o caso.

Query strings de log e de exportação de estatística carregam com frequência dado pessoal: termo de busca, e-mail como parâmetro, identificador associável a uma conta. Como aqui a separação acontece na própria página, nada disso sai do seu aparelho.

É a condição para conseguir olhar uma exportação dessas com uma ferramenta online. Um serviço que a separasse num servidor teria recebido a linha e a teria nos logs dele — com exatamente o tipo de dado cujo compartilhamento é o motivo da maioria das políticas internas.