# Decodificador de mensagens HTTP

> Cole uma requisição ou resposta HTTP/1.1 bruta e leia-a decodificada: a linha de requisição ou de status contra os registros da IANA, cada campo arquivado sob a parte da especificação que o define, a decisão de enquadramento que a RFC 9112 toma para o corpo (qual das oito regras se aplica, Content-Length contra os bytes presentes, Transfer-Encoding sobrepondo-o, os chunks decodificados um a um com os trailers), e as credenciais e cookies que a mensagem carrega, expostos e mascarados. A metade que só decodifica do inspetor de um proxy de interceptação: nunca envia, repete nem altera.

- Tool: https://ronutz.com/pt-BR/tools/http-message-decoder
- Family: Web e HTTP

---

## O que faz

Lê uma mensagem HTTP/1.1 bruta, requisição ou resposta, do jeito que uma captura, o log de um proxy, um rastro de `curl -v` ou um exemplo de RFC a entrega, e a decodifica sem enviar nada:

- **A linha inicial.** Uma linha de requisição é lida como método, alvo e versão: o método contra a tabela que a [comparação de métodos HTTP](https://ronutz.com/pt-BR/tools/http-methods-comparison) usa (seguro, idempotente, a especificação que o define), o alvo contra as quatro formas da RFC 9112, seção 3.2 (origin-form `/caminho`, absolute-form `esquema://host/caminho`, authority-form `host:porta` para CONNECT, asterisk-form `*` para um OPTIONS ao servidor inteiro), a versão contra `HTTP-version = HTTP-name "/" DIGIT "." DIGIT`. Uma linha de status é lida como versão, código de três dígitos e frase de razão; o código é procurado no registro de códigos de status da IANA, e a frase enviada aparece ao lado da do registro, já que a RFC 9110 diz que as frases de razão "are only recommendations" e um cliente "SHOULD ignore the reason-phrase content".
- **Os campos.** Cada linha `nome: valor` é conferida contra o registro de nomes de campo da IANA (permanente, descontinuado, obsoleto; o resto é não registrado, e um prefixo `X-` é anotado com a RFC 6648) e arquivada sob a parte da especificação que a define: enquadramento (RFC 9112), roteamento e conexão, metadados da mensagem, contexto de requisição e de resposta, representação, negociação, requisições condicionais, requisições de intervalo (RFC 9110, seções 6 a 14), cache (RFC 9111), cookies (rfc6265bis), política de segurança, CORS e metadados de fetch (as especificações Fetch e HTML do WHATWG, CSP, HSTS), WebSocket, proxies e CDNs, WebDAV. Dobras de linha obsoletas são juntadas, espaço antes de um dois-pontos é apontado, campos singulares repetidos são apontados, e valores HTTP-date são conferidos contra os três formatos da RFC 9110, seção 5.6.7.
- **O enquadramento.** Qual das oito regras da RFC 9112, seção 6.3 decide onde o corpo termina: uma resposta que não pode carregar corpo (HEAD, 1xx, 204, 304), um túnel CONNECT, Transfer-Encoding sobrepondo Content-Length, chunked como codificação final, um Content-Length inválido, um válido, uma requisição sem nenhum dos dois (tamanho zero), uma resposta sem nenhum dos dois (lida até fechar). Content-Length é validado contra `1*DIGIT`, valores repetidos são comparados, e o tamanho declarado é comparado com os octetos realmente colados. Um corpo em chunks é decodificado pelo algoritmo da seção 7.1.3: tamanho, extensões e dados de cada chunk, o último chunk, os campos trailer, o tamanho decodificado e o que sobrar depois do fim do corpo, que um receptor leria como a próxima mensagem.
- **Credenciais e cookies.** `Authorization` e `Proxy-Authorization` são expostos com o valor mascarado; credenciais Basic são decodificadas só até o usuário (RFC 7617: usuário, dois-pontos e senha, em Base64; "not a secure method of user authentication"), e um token Bearer com forma de JWT é encaminhado ao [decodificador de JWT](https://ronutz.com/pt-BR/tools/jwt) sem viajar no link. Os pares de `Cookie` são listados com valores mascarados; cada `Set-Cookie` é lido quanto a Secure, HttpOnly, SameSite (Lax por padrão), as exigências dos prefixos `__Secure-` e `__Host-`, Max-Age sobre Expires e o formato de Expires.
- **Encaminhamentos.** O código de status ao [explicador de códigos de status](https://ronutz.com/pt-BR/tools/http-status-code-explainer), o método à comparação de métodos, a URL (quando não traz query) ao [inspetor de URL](https://ronutz.com/pt-BR/tools/url-inspector), os cabeçalhos de segurança ao avaliador de [cabeçalhos seguros](https://ronutz.com/pt-BR/tools/secure-headers), uma requisição ao [tradutor de requisições HTTP](https://ronutz.com/pt-BR/tools/http-request-translator) para as formas curl, fetch, HTTPie, Python e PowerShell.

## As regras

Vinte e oito regras, H1 a H28, cada uma citando a sua frase: a linha inicial (H1, H16, H17, H18, H24, H25), Host (H2), sintaxe dos campos (H3, H4, H5, H20, H21, H22, H23, H28), enquadramento (H6, H7, H8, H9, H10, H11, H12, H13, H26), credenciais e cookies (H14, H15), HTTP-dates (H19) e opções de conexão (H27). Os achados aparecem por linha e marcados numa cópia numerada da mensagem.

## O que deliberadamente não faz

- Nunca envia, repete, altera nem faz fuzzing: a metade que só decodifica de um inspetor (D-53). O [tradutor de requisições HTTP](https://ronutz.com/pt-BR/tools/http-request-translator) é onde uma requisição vira um comando que você mesmo roda.
- Não avalia cabeçalhos de segurança nem decodifica JWTs por conta própria; as ferramentas que o fazem estão a um clique, e o segredo nunca viaja no link.
- Não modela o enquadramento de HTTP/2 ou HTTP/3: esses levam os campos em quadros binários, e uma colagem em texto deles já é a saída de um decodificador.

## Limites

- As contagens de octetos são contagens UTF-8 do texto colado; um corpo com conteúdo binário ou outro charset mede diferente no fio, e uma colagem costuma perder bytes finais, então uma divergência de Content-Length é relatada como fato sobre a colagem.
- O esquema da URL de uma requisição não está numa mensagem HTTP/1.1; `http` é presumido quando a URL é montada a partir de Host e um alvo origin-form.
- Se uma resposta responde a um HEAD não se sabe só pela resposta; a regra 1 é aplicada só a 1xx, 204 e 304.
- Os valores dos campos aparecem como escritos, exceto credenciais e cookies, que são mascarados. A mensagem fica no navegador; um link de compartilhamento é revisado antes de ser criado, porque uma mensagem costuma carregar uma sessão.

## Fontes

- [RFC 9112: HTTP/1.1](https://www.rfc-editor.org/rfc/rfc9112.html) (lida em 2026-10-05): seções 2.1, 2.2, 2.3, 3, 3.2, 4, 5, 5.2, 6.1, 6.3, 7.1
- [RFC 9110: HTTP Semantics](https://www.rfc-editor.org/rfc/rfc9110.html) (lida em 2026-10-05): seções 5.1, 5.3, 5.5, 5.6.7, 7.2, 7.6.1, 8.6, 9.2.1, 9.2.2, 11.1, 11.6.2, 15, 15.1
- [RFC 9111: HTTP Caching](https://www.rfc-editor.org/rfc/rfc9111.html) (lida em 2026-10-05)
- [IANA: HTTP Field Name Registry](https://www.iana.org/assignments/http-fields/field-names.csv) (lido em 2026-10-05)
- [IANA: HTTP Status Code Registry](https://www.iana.org/assignments/http-status-codes/http-status-codes-1.csv) (lido em 2026-10-05)
- [draft-ietf-httpbis-rfc6265bis-22: Cookies: HTTP State Management Mechanism](https://www.ietf.org/archive/id/draft-ietf-httpbis-rfc6265bis-22.html) (lido em 2026-10-05)
- [RFC 7617: The 'Basic' HTTP Authentication Scheme](https://www.rfc-editor.org/rfc/rfc7617.html) (lida em 2026-10-05)
- [RFC 6648: Deprecating the "X-" Prefix and Similar Constructs in Application Protocols](https://www.rfc-editor.org/rfc/rfc6648.html) (lida em 2026-10-05)

## Standards and references

- [RFC 9112: HTTP/1.1 (message format, request line, status line, field syntax, obsolete line folding, Transfer-Encoding, Content-Length, message body length, chunked transfer coding)](https://www.rfc-editor.org/rfc/rfc9112.html) - Sections 2.1 and 2.2 (message format, leading empty lines, bare CR, LF alone), 2.3 (HTTP-version), 3 and 3.2 (request line, the four request-target forms, Host required in HTTP/1.1), 4 (status line, reason phrase), 5 and 5.2 (field lines, no whitespace before the colon, obs-fold), 6.1 (Transfer-Encoding, chunked final, HTTP/1.0), 6.3 (the eight message body length rules), 7.1 (chunked coding and its decoding algorithm)
- [RFC 9110: HTTP Semantics (field names, field order, field values, HTTP-date, Host, Connection, Content-Length, safe and idempotent methods, authentication, status code classes)](https://www.rfc-editor.org/rfc/rfc9110.html) - Sections 5.1 (field names case-insensitive), 5.3 (combining field lines; the Set-Cookie exception), 5.5 (CR, LF, NUL in values), 5.6.7 (the three HTTP-date formats), 7.2 (Host), 7.6.1 (Connection), 8.6 (Content-Length), 9.2.1 and 9.2.2 (safe and idempotent methods), 11.1 and 11.6.2 (authentication schemes, Authorization), 15 and 15.1 (status code classes, reason phrases as recommendations)
- [RFC 9111: HTTP Caching (Age, Cache-Control, Expires, Pragma deprecated, Warning obsoleted)](https://www.rfc-editor.org/rfc/rfc9111.html) - the caching fields the registry refers to it for, with Pragma deprecated (Section 5.4) and Warning obsoleted (Section 5.5)
- [IANA: Hypertext Transfer Protocol (HTTP) Field Name Registry (permanent, deprecated and obsoleted rows)](https://www.iana.org/assignments/http-fields/field-names.csv) - the registered field names, their status and their defining reference, used to name each field, mark deprecated and obsoleted ones and tell registered from unregistered
- [IANA: Hypertext Transfer Protocol (HTTP) Status Code Registry](https://www.iana.org/assignments/http-status-codes/http-status-codes-1.csv) - the assigned status codes, their descriptions (the recommended reason phrases) and references, used to read the status line and mark unassigned codes
- [draft-ietf-httpbis-rfc6265bis-22: Cookies: HTTP State Management Mechanism (the registry's reference for Cookie and Set-Cookie)](https://www.ietf.org/archive/id/draft-ietf-httpbis-rfc6265bis-22.html) - Set-Cookie and Cookie syntax (Sections 4.1.1 and 4.2.1), the __Secure- and __Host- prefix requirements (4.1.3), SameSite's default of Lax, Secure cookies sent only over secure channels, Max-Age over Expires
- [RFC 7617: The 'Basic' HTTP Authentication Scheme](https://www.rfc-editor.org/rfc/rfc7617.html) - credentials are user-id, a colon and the password, Base64-encoded; a user-id cannot contain a colon; the scheme is not a secure method of user authentication and transmits the entity in cleartext
- [RFC 6648 (BCP 178): Deprecating the X- Prefix and Similar Constructs in Application Protocols](https://www.rfc-editor.org/rfc/rfc6648.html) - new parameters SHOULD NOT be prefixed with X-; implementations MUST NOT make assumptions about a parameter's status from the prefix

## Related reading

- [HTTP/0.9 vs 1.0 vs 1.1 vs 2 vs 3: cinco versões do protocolo da web](https://ronutz.com/pt-BR/learn/http-versions-09-to-3.md): De um GET de uma linha, que só buscava HTML, a um protocolo multiplexado rodando sobre QUIC: o que cada versão do HTTP acrescentou, por que ela foi necessária e qual RFC a define hoje, incluindo a reorganização de 2022, que separou a semântica do HTTP (RFC 9110) da sintaxe de transmissão de cada versão.
- [Onde uma mensagem HTTP/1.1 termina: Content-Length, chunked e as oito regras](https://ronutz.com/pt-BR/learn/http-message-framing-content-length-and-chunked.md): Uma conexão HTTP/1.1 é um fluxo de bytes com mensagens postas uma após a outra, e nada marca onde uma para além das regras que as duas pontas combinam. A RFC 9112 dá oito delas, em ordem de precedência, e todo ataque de request smuggling dos últimos vinte anos são duas implementações aplicando regras diferentes aos mesmos bytes. Aqui estão as regras, a codificação chunked decodificada à mão, o que o Content-Length promete e o que dá errado quando a promessa e os bytes discordam.