Pesquisa de cabeçalhos HTTP

5 de 2 avaliações

A Pesquisa de cabeçalhos HTTP é uma ferramenta gratuita que obtém todos os cabeçalhos de resposta HTTP devolvidos por um URL num pedido GET típico.

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

Os cabeçalhos de resposta HTTP são metadados que um servidor Web envia antes do corpo da resposta, como uma página HTML, uma imagem ou um documento JSON. Indicam ao cliente como interpretar, armazenar em cache, redirecionar ou proteger a resposta.

Uma resposta HTTP/1.x começa normalmente por uma linha de estado HTTP, seguida dos cabeçalhos. Em HTTP/2 e HTTP/3, o estado equivalente é transmitido no pseudocabeçalho :status. Embora a linha de estado HTTP/1.x esteja tecnicamente separada dos cabeçalhos, é habitual apresentá-la juntamente com estes, pois indica se o pedido foi bem-sucedido. Um estado como 200 significa que o recurso foi devolvido, 301 ou 302 indica um redirecionamento, 404 significa que o recurso não foi encontrado e 500 indica um erro do lado do servidor.

Os cabeçalhos podem ter origem no servidor de origem, num proxy inverso ou numa rede de distribuição de conteúdos, como a Cloudflare. Alguns são adicionados ou removidos à medida que a resposta passa por esses sistemas. Por isso, o resultado pode descrever mais do que apenas a aplicação que gerou a página.

Como faço uma pesquisa de cabeçalhos HTTP?

Introduz o URL completo que pretendes verificar, incluindo o esquema, por exemplo, https://www.example.com/account. A ferramenta envia um pedido GET típico a partir do respetivo servidor e apresenta os cabeçalhos HTTP recebidos desse URL.

Para comparares corretamente os cabeçalhos de resposta, utiliza exatamente as variantes de URL que pretendes analisar. Os cabeçalhos de http://example.com, https://example.com e https://www.example.com podem ser diferentes, pois cada endereço pode ter os seus próprios redirecionamentos, regras de cache e configuração de servidor.

A sintaxe do URL também afeta o pedido:

  • Os espaços não são caracteres válidos num URL sem codificação e, normalmente, têm de ser codificados através de percentagem, geralmente como %20 num caminho.
  • ? inicia o componente de consulta. Já & e = são frequentemente utilizados em codificações de consultas semelhantes às dos formulários, mas não desempenham essas funções em todas as cadeias de consulta.
  • Os nomes de domínio com acentos ou caracteres não latinos são processados através de IDNA e representados como A-labels ASCII, geralmente começados por xn--. Os caracteres do caminho são, em regra, codificados como bytes UTF-8 e depois através de percentagem.
  • Um fragmento iniciado por # é processado pelo navegador e não é enviado no pedido HTTP.
  • Não existe um comprimento máximo universal para um URL. Os URLs muito longos podem ser rejeitados por um servidor, proxy ou aplicação.

Como interpreto o resultado dos cabeçalhos HTTP?

Analisa os cabeçalhos relacionados com o problema que estás a investigar. Os nomes dos cabeçalhos não distinguem maiúsculas de minúsculas, embora a sintaxe dos respetivos valores possa fazer essa distinção.

Campo do resultado O que indica
Location O destino de um redirecionamento. Acompanha normalmente um estado 3xx.
Content-Type O tipo de conteúdo devolvido, como text/html, application/json ou image/png.
Content-Length O tamanho declarado do corpo da resposta em bytes, quando fornecido pelo servidor. Pode ser omitido em respostas segmentadas ou geradas dinamicamente.
Cache-Control and Expires As instruções de cache e, quando indicado, o momento em que a resposta expira.
Age A idade calculada, em segundos, de uma resposta em cache desde que foi gerada ou validada pela última vez, podendo incluir o tempo passado em caches a montante.
ETag and Last-Modified Validadores que os clientes podem utilizar para verificar se o conteúdo em cache foi alterado.
Set-Cookie Um pedido para guardar um cookie, incluindo atributos como Secure, HttpOnly e SameSite.
Content-Security-Policy Regras do navegador que restringem os scripts, estilos, frames e outros recursos que uma página pode carregar.
Strict-Transport-Security Uma instrução que indica aos navegadores compatíveis que devem utilizar HTTPS durante o período especificado.

Outros cabeçalhos podem ser específicos da aplicação. Por exemplo, Access-Control-Allow-Origin controla que origens podem ler uma resposta através de pedidos entre origens efetuados pelo navegador. Um cabeçalho Server pode identificar software ou um proxy, mas não constitui prova fiável da plataforma subjacente, uma vez que os administradores podem alterá-lo ou removê-lo.

Cenários práticos de diagnóstico

Os problemas de redirecionamento são um motivo comum para analisar cabeçalhos. Imagina que https://example.com/old-page devolve o estado 301 com Location: https://example.com/new-page. Isto significa que o servidor está a instruir o cliente a pedir o novo endereço. A verificação sucessiva de cada destino pode revelar um ciclo de redirecionamento ou uma mudança inesperada entre HTTP e HTTPS.

Se uma página desatualizada estiver a ser servida através da Cloudflare ou de outra CDN, analisa Cache-Control, Age, ETag e eventuais cabeçalhos de cache específicos do fornecedor. Um valor Age elevado indica a idade calculada da resposta em cache, podendo incluir o tempo passado em caches a montante, e não há quanto tempo um determinado intermediário a mantém. Também não prova que todas as caches regionais tenham a mesma versão.

Quando uma API funciona num script do lado do servidor, mas falha no navegador, verifica Content-Type e os cabeçalhos de resposta CORS, incluindo Access-Control-Allow-Origin. Se um endpoint JSON devolver text/html, pode estar, na realidade, a apresentar uma página de erro ou um ecrã de início de sessão. A falta de permissão entre origens pode levar o navegador a bloquear o acesso, mesmo que o servidor tenha devolvido o estado 200.

Os cabeçalhos também podem ajudar a analisar um site que parece indisponível. Uma resposta 503 aponta para uma falha temporária no servidor ou num sistema a montante, enquanto 404 significa que o caminho pedido não foi encontrado. Contudo, os cabeçalhos não permitem diagnosticar todas as falhas. Se a resolução DNS, a ligação TCP ou a negociação TLS falhar antes de existir uma resposta HTTP, poderá não haver cabeçalhos de resposta para analisar. O Ping permite fazer uma verificação de conectividade separada, enquanto o Verificador de HTTP/2 verifica a compatibilidade com o protocolo.

Porque pode um resultado correto parecer errado?

Um resultado correto pode ser diferente do que aparece no teu navegador, pois as caches, os registos DNS e o contexto do pedido podem encaminhar os dois pedidos para respostas distintas. Esta pesquisa é executada no servidor, pelo que pode chegar a outro nó da CDN ou resolver um registo DNS alterado recentemente mais cedo ou mais tarde do que a tua rede local.

Os navegadores também enviam os seus próprios cookies, tipos de conteúdo aceites, idiomas e validadores de cache. Assim, uma página WordPress com sessão iniciada pode devolver regras de cache diferentes das recebidas por um pedido anónimo feito pelo servidor. O encaminhamento geográfico e os sistemas de gestão de bots também podem variar a resposta consoante a rede de origem ou os cabeçalhos do pedido.

Depois de uma alteração ao DNS, os resolvedores com dados em cache podem continuar a utilizar o registo anterior até terminar o respetivo tempo de vida. Quando o tráfego já chega ao novo servidor, um objeto antigo da CDN ou a cache do navegador ainda pode devolver conteúdo anterior. Verifica separadamente o anfitrião resolvido, limpa as caches quando for adequado e compara o URL exato, em vez de assumires que todos os nomes de anfitrião utilizam a mesma configuração.

Perguntas frequentes

Esta pesquisa mostra os cabeçalhos do pedido?

Não. A ferramenta obtém os cabeçalhos de resposta devolvidos pelo URL num pedido GET típico. Os cabeçalhos do pedido são os metadados enviados para o servidor. Para os analisares por completo, tens de utilizar separadamente as ferramentas de programador do navegador, os registos do servidor ou um cliente de linha de comandos.

Os URLs introduzidos na ferramenta são privados?

A pesquisa é efetuada no servidor. Os dados que introduzes são enviados para esse servidor através de HTTPS e não são armazenados. Evita introduzir URLs que contenham palavras-passe, tokens de acesso ou parâmetros de consulta sensíveis, pois o servidor de destino também receberá esses valores quando o pedido for feito.

Os cabeçalhos HTTP explicam um aviso de certificado?

Normalmente, não por si só. A ligação TLS é estabelecida antes de a resposta HTTP ser enviada. Por isso, um certificado expirado, um nome de anfitrião incompatível ou um emissor não fidedigno pode impedir a devolução de quaisquer cabeçalhos. Se o aviso do navegador surgir antes de a página carregar, analisa separadamente o certificado e a respetiva cadeia.

Porque são devolvidos vários cabeçalhos Set-Cookie?

Uma resposta pode definir mais do que um cookie, e cada cookie utiliza o seu próprio campo Set-Cookie. Não os combines como se fossem uma lista separada por vírgulas, pois as datas de expiração dos cookies também podem conter vírgulas. Analisa 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 apresenta os cabeçalhos de resposta e descarta o corpo. Diferentes versões do curl, cabeçalhos de pedido, definições de redirecionamento e localizações de rede podem produzir resultados distintos. Compara essas condições antes de considerares que uma diferença resulta de uma falha no servidor.

Partilhar

Ferramentas Populares