Pesquisa de cabeçalhos HTTP

A Pesquisa de cabeçalhos HTTP é uma ferramenta gratuita que recupera todos os cabeçalhos de resposta HTTP retornados por uma URL em uma solicitação GET típica.

O que são cabeçalhos de resposta HTTP?

Cabeçalhos de resposta HTTP são metadados enviados pelo servidor web antes do corpo da resposta, como uma página HTML, uma imagem ou um documento JSON. Eles informam ao cliente como interpretar, armazenar em cache, redirecionar ou proteger a resposta.

Uma resposta HTTP/1.x normalmente começa com uma linha de status HTTP, seguida pelos cabeçalhos. Em HTTP/2 e HTTP/3, o status equivalente é enviado no pseudocabeçalho :status. Tecnicamente, a linha de status HTTP/1.x não faz parte dos cabeçalhos, mas costuma ser exibida junto com eles porque indica se a solicitação foi bem-sucedida. Um status 200 significa que o recurso foi retornado, 301 ou 302 indica um redirecionamento, 404 significa que o recurso não foi encontrado e 500 indica um erro no servidor.

Os cabeçalhos podem vir do servidor de origem, de um proxy reverso ou de uma rede de distribuição de conteúdo, como a Cloudflare. Alguns são adicionados ou removidos durante a passagem da resposta por esses sistemas. Por isso, o resultado pode descrever mais do que apenas a aplicação que gerou a página.

Como consultar os cabeçalhos HTTP?

Digite a URL completa que deseja verificar, incluindo o esquema, como https://www.example.com/account. A ferramenta envia uma solicitação GET típica a partir do próprio servidor e retorna os cabeçalhos HTTP recebidos dessa URL.

Para comparar cabeçalhos de resposta com precisão, use exatamente as variações de URL que deseja investigar. Os cabeçalhos de http://example.com, https://example.com e https://www.example.com podem ser diferentes, pois cada endereço pode ter seus próprios redirecionamentos, regras de cache e configurações de servidor.

A sintaxe da URL também afeta a solicitação:

• Espaços não são caracteres válidos em uma URL sem codificação e normalmente precisam ser codificados por porcentagem, geralmente como %20 em um caminho.
• ? inicia o componente de consulta, enquanto & e = costumam ser usados em codificações de consulta no estilo de formulários, mas não exercem essas funções em todas as strings de consulta.
• Domínios com caracteres acentuados ou não latinos são processados por IDNA e representados como rótulos A em ASCII, normalmente iniciados por xn--. Já os caracteres do caminho geralmente são codificados como bytes UTF-8 e depois por porcentagem.
• Um fragmento iniciado por # é processado pelo navegador e não é enviado na solicitação HTTP.
• Não existe um limite máximo universal para o tamanho de uma URL. URLs muito longas podem ser rejeitadas por um servidor, proxy ou aplicação.

Como interpretar o resultado dos cabeçalhos HTTP?

Examine os cabeçalhos relacionados ao problema que está investigando. Os nomes dos cabeçalhos não diferenciam maiúsculas de minúsculas, embora a sintaxe de seus valores possa fazer essa distinção.

Outros cabeçalhos podem ser específicos da aplicação. Por exemplo, Access-Control-Allow-Origin controla quais origens podem ler uma resposta por meio de solicitações entre origens no navegador. O cabeçalho Server pode identificar um software ou proxy, mas não é uma prova confiável da plataforma usada, pois os administradores podem alterá-lo ou removê-lo.

Cenários práticos de solução de problemas

Problemas de redirecionamento são um motivo comum para examinar cabeçalhos. Suponha que https://example.com/old-page retorne o status 301 com Location: https://example.com/new-page. Isso significa que o servidor está instruindo o cliente a solicitar o novo endereço. Verificar repetidamente cada destino pode revelar um loop de redirecionamento ou uma mudança inesperada entre HTTP e HTTPS.

Se uma página desatualizada estiver sendo servida pela Cloudflare ou por outra CDN, examine Cache-Control, Age, ETag e qualquer cabeçalho de cache específico do provedor. Um valor alto em Age indica a idade calculada da resposta armazenada em cache, possivelmente incluindo o tempo em caches anteriores, e não há quanto tempo um intermediário específico a mantém. Isso não comprova que todos os caches regionais tenham a mesma versão.

Quando uma API funciona em um script executado no servidor, mas falha no navegador, examine Content-Type e os cabeçalhos de resposta CORS, incluindo Access-Control-Allow-Origin. Se um endpoint JSON retornar text/html, ele pode estar fornecendo uma página de erro ou tela de login. A ausência de permissão entre origens pode fazer o navegador bloquear o acesso, mesmo que o servidor tenha retornado o status 200.

Os cabeçalhos também podem ajudar a investigar um site que parece estar indisponível. Uma resposta 503 aponta para uma falha temporária no servidor ou em um serviço anterior, enquanto 404 significa que o caminho solicitado não foi encontrado. No entanto, os cabeçalhos não permitem diagnosticar todas as falhas. Se a resolução DNS, a conexão TCP ou a negociação TLS falhar antes de existir uma resposta HTTP, talvez não haja cabeçalhos de resposta para examinar. O Ping oferece uma verificação de conectividade separada, enquanto o Verificador de HTTP/2 permite conferir a compatibilidade com o protocolo.

Por que um resultado correto ainda pode parecer errado?

Um resultado correto pode ser diferente do que aparece no seu navegador porque caches, registros DNS e o contexto da solicitação podem direcionar as duas requisições para respostas distintas. A consulta é executada no servidor, então pode chegar a outro nó da CDN ou resolver um registro DNS alterado recentemente antes ou depois da sua rede local.

Os navegadores também enviam seus próprios cookies, tipos de conteúdo aceitos, idiomas e validadores de cache. Por isso, uma página do WordPress com usuário conectado pode retornar regras de cache diferentes das recebidas por uma solicitação anônima feita pelo servidor. O roteamento geográfico e os sistemas de gerenciamento de bots também podem variar a resposta conforme a rede de origem ou os cabeçalhos da solicitação.

Depois de uma alteração no DNS, os resolvedores com cache podem continuar usando o registro anterior até o fim do tempo de vida dele. Mesmo quando o tráfego já chega ao novo servidor, um objeto antigo na CDN ou no cache do navegador ainda pode retornar o conteúdo anterior. Verifique separadamente o host resolvido, limpe os caches quando apropriado e compare a URL exata, em vez de presumir que todos os nomes de host usam a mesma configuração.

Perguntas frequentes

A consulta mostra os cabeçalhos da solicitação?

Não. Ela recupera os cabeçalhos de resposta retornados pela URL em uma solicitação GET típica. Os cabeçalhos da solicitação são os metadados enviados ao servidor. Para examiná-los por completo, é preciso usar separadamente as ferramentas de desenvolvedor do navegador, os logs do servidor ou um cliente de linha de comando.

As URLs digitadas na ferramenta são privadas?

A consulta é realizada no servidor. Os dados inseridos são enviados a esse servidor por HTTPS e não são armazenados. Evite digitar URLs que contenham senhas, tokens de acesso ou parâmetros de consulta confidenciais, pois o servidor de destino também receberá esses valores quando a solicitação for feita.

Os cabeçalhos HTTP explicam um aviso de certificado?

Geralmente, não por si só. A conexão TLS é estabelecida antes do envio da resposta HTTP. Portanto, um certificado expirado, um nome de host incompatível ou um emissor não confiável pode impedir o retorno de qualquer cabeçalho. Se o aviso do navegador aparecer antes de a página carregar, examine separadamente o certificado e sua cadeia.

Por que a resposta traz vários cabeçalhos Set-Cookie?

Uma resposta pode definir mais de um cookie, e cada um usa seu próprio campo Set-Cookie. Não os combine como se fossem uma lista separada por vírgulas, pois as próprias datas de expiração dos cookies podem conter vírgulas. Examine separadamente o domínio, o caminho e os atributos de segurança de cada cookie.

Posso comparar o resultado com o curl?

Sim. Um comando como curl -D - https://example.com/ -o /dev/null exibe os cabeçalhos de resposta e descarta o corpo. Versões do curl, cabeçalhos da solicitação, configurações de redirecionamento e locais de rede podem produzir resultados diferentes. Antes de considerar uma diferença como falha do servidor, tente reproduzir essas mesmas condições.