Analisador de Cabeçalhos HTTP

Analise cabeçalhos HTTP brutos de requisição ou resposta em uma tabela estruturada. Extraia a linha de status, cabeçalhos, cookies e informações de tipo de conteúdo instantaneamente.

Detecção Automática de Tipo Extração de Cookies Análise de Content-Type

Como Usar o Analisador de Cabeçalhos HTTP

1

Cole os Cabeçalhos

Copie os cabeçalhos HTTP brutos das Ferramentas de Desenvolvedor do navegador (aba Rede) ou de qualquer fonte e cole-os na área de entrada.

2

Análise Automática

Os cabeçalhos são analisados instantaneamente em uma tabela estruturada, detectando automaticamente se é uma requisição ou resposta.

3

Inspecione os Detalhes

Revise a linha de status, cabeçalhos individuais, cookies extraídos e detalhamento do tipo de conteúdo.

O que são Cabeçalhos HTTP?

Cabeçalhos HTTP são pares chave-valor enviados entre um cliente e servidor em requisições e respostas HTTP. Eles carregam metadados sobre a requisição ou resposta, como tipo de conteúdo, regras de cache, tokens de autenticação e informações de cookies. Compreender os cabeçalhos é essencial para depurar aplicações web, otimizar performance e garantir segurança.

Cabeçalhos de requisição

Enviados pelo cliente ao servidor, incluindo Host, User-Agent, Accept, Authorization e Cookie.

Cabeçalhos de resposta

Enviados pelo servidor ao cliente, incluindo Content-Type, Set-Cookie, Cache-Control e X-Request-Id.

Cabeçalhos de segurança

Cabeçalhos como Content-Security-Policy, Strict-Transport-Security e X-Frame-Options que melhoram a segurança.

Perguntas Frequentes

Ele analisa tanto cabeçalhos de requisição quanto de resposta?

Sim. O analisador detecta automaticamente se a entrada é uma requisição ou resposta HTTP com base na primeira linha e analisa adequadamente. Linhas de requisição começam com um método HTTP (GET, POST, etc.) enquanto linhas de resposta começam com HTTP/versão.

Pode extrair cookies de cabeçalhos Set-Cookie?

Sim. Cabeçalhos Set-Cookie são analisados em cookies individuais mostrando nome, valor e todas as flags como HttpOnly, Secure, SameSite, Path, Domain e Max-Age.

Quais formatos de cabeçalho são aceitos?

Formato padrão de cabeçalho HTTP/1.1 e HTTP/2 com um cabeçalho por linha no formato "Nome: Valor". Você pode copiar cabeçalhos diretamente das ferramentas de desenvolvedor do navegador.

Que cabeçalhos HTTP aparecem com maior frequência?

As requisições transportam tipicamente host, user-agent, accept, accept-encoding e cookie; as respostas devolvem content-type, content-length, cache-control, set-cookie e date. O tráfego de API acrescenta authorization e content-type: application/json à entrada e cabeçalhos de rate-limit à saída. A RFC 9110 (semântica HTTP, 2022) é a referência moderna que define todos estes campos.

Qual é a diferença entre cabeçalhos de requisição e de resposta?

Os cabeçalhos de requisição (host, authorization, accept-*) descrevem o que o cliente pretende; os cabeçalhos de resposta (location, set-cookie, retry-after) descrevem o que regressou. Alguns campos aparecem em ambos os sentidos (cache-control, content-type) e alguns regem a própria ligação (connection: keep-alive) em vez do conteúdo da mensagem. Este analisador anota a que lado pertence cada cabeçalho.

Como são tratados os cabeçalhos HTTP duplicados?

De acordo com a RFC 9110, a maioria dos campos repetidos é combinada numa única lista separada por vírgulas - duas linhas cache-control e uma linha com o valor no-cache, no-store são equivalentes. O Set-Cookie é a exceção documentada: nunca pode ser combinado por vírgulas, porque as datas Expires contêm vírgulas, pelo que os proxies têm de reencaminhar cada Set-Cookie separadamente. Essa exceção é uma fonte clássica de erros em proxies.

O que mudou nos cabeçalhos com o HTTP/2 e o HTTP/3?

Os nomes dos campos passaram a ser em minúsculas e viajam como frames binárias comprimidas com HPACK ou QPACK; cada requisição abre o seu próprio stream e os cabeçalhos por ligação, como o Host, foram substituídos pelo pseudo-cabeçalho :authority, juntamente com :method, :scheme e :path. Semanticamente, os campos continuam a seguir a RFC 9110 - mudou o formato de transmissão, não o vocabulário.

Que sintaxe de cabeçalho é realmente inválida?

Espaços em branco entre o nome do campo e os dois pontos (Header : value) - tanto a análise de HTTP/1.1 como a especificação HTTP/2 rejeitam-no, para evitar request smuggling. Também é inválido: espaços ou bytes não ASCII no nome do campo, carateres de controlo nos valores e obs-fold (um cabeçalho continuado por uma linha indentada), que a RFC 9110 marca como obsoleto - substitua-o por uma única linha ou por um valor em lista.

{-- * External Resources Component(#18 Phase 3b 内容佐证工程) * 工具页「权威引用」区块:RFC / W3C / WHATWG / ECMA / IANA / 官方规范站 / Wikipedia。 * * - 接受 :slug 属性 → 经 config/tool-sources.php 家族矩阵渲染该工具的权威引用 * - slug 未命中映射时不渲染(无权威来源的工具静默跳过) * - 链接 title 保持英文(引用源专名);description 经 * common.resources.descriptions.{key} 本地化,lang 未命中回退英文(线上不裸奔) * - 链接保持 dofollow(rel="noopener noreferrer") * * @param string|null $slug --}}