# HTTP a partir da linha de requisição: o que uma mensagem quer dizer e como ela viaja

> Toda troca HTTP tem duas mensagens, uma requisição e uma resposta, e desde junho de 2022 o padrão descreve essas mensagens em duas camadas: o que a mensagem significa (métodos, códigos de status, campos de header), definido uma única vez para todas as versões, e como os bytes dela trafegam, definido separadamente para cada versão. É o mapa da série sobre HTTP: qual artigo lê qual parte da mensagem, e em que ordem.

Source: https://ronutz.com/pt-BR/learn/http-from-the-request-line  
Updated: 2026-10-06  
Related tools: https://ronutz.com/pt-BR/tools/http-methods-comparison, https://ronutz.com/pt-BR/tools/curl-command-explainer

---

O HTTP parece uma lista enorme de coisas para aprender: os métodos, dezenas de códigos de status, um registro extenso de campos de header (cabeçalho), cookies, proxies, cinco versões. Na verdade, ele é menor do que essa lista. Toda troca é uma requisição e uma resposta, e cada item da lista ou é uma parte dessas duas mensagens, ou é uma forma de transportá-las.

## Uma troca, duas mensagens

O padrão resume o protocolo inteiro numa frase: "HTTP is a stateless request/response protocol for exchanging 'messages' across a connection" (RFC 9110, seção 3.4), ou seja, um protocolo de requisição e resposta, stateless (sem estado), que troca mensagens por uma conexão. O cliente envia uma requisição: um método, que diz o que ele quer que seja feito; o alvo, sobre o qual isso deve ser feito; campos de header que detalham o pedido; e, às vezes, um corpo. O servidor responde com um código de status, que diz como foi, campos de header próprios e, normalmente, um corpo.

Essa também é a ordem certa para aprender. Leia a requisição de cima para baixo, do jeito que o servidor lê: a linha de requisição (a request line, com o método e o alvo), depois os campos, depois o corpo e o ponto em que ele termina. Leia a resposta do mesmo jeito: o status, depois os campos. A série segue essa ordem e depois passa para as camadas em volta das mensagens.

## Duas camadas desde junho de 2022

Durante a maior parte da sua história, o padrão do HTTP/1.1 misturava dois tipos de regra. Umas dizem o que a mensagem significa: o que um GET promete, o que um 304 obriga um cache a fazer, para que serve o campo Host. Outras dizem como a mensagem é organizada em bytes: linhas de texto que terminam com um carriage return e um line feed, e um tamanho ou uma codificação chunked que mostra onde o corpo termina.

Em junho de 2022, a Internet Engineering Task Force (IETF) republicou o HTTP com os dois tipos de regra separados. A RFC 9110, HTTP Semantics, "defines aspects of the protocol that are shared by all versions", ou seja, reúne o que vale para todas as versões: os métodos, os códigos de status, os campos. Cada versão tem, então, um documento próprio para o formato em que a mensagem trafega: a RFC 9112 para as mensagens de texto do HTTP/1.1, a RFC 9113 para os frames binários e os streams multiplexados do HTTP/2, e a RFC 9114 para o HTTP/3, que roda sobre o transporte QUIC em vez do TCP.

Essa separação é a ideia mais útil da série. Um 404 significa a mesma coisa no HTTP/1.1 e no HTTP/3, e um GET faz as mesmas promessas nos dois; o que muda é o framing (a forma como os bytes que carregam tudo isso são delimitados). Quando algo quebra, pergunte em que camada quebrou. Um servidor que responde 403 a uma requisição que deveria aceitar tem um problema de significado. Dois equipamentos que discordam sobre onde uma mensagem termina têm um problema de framing, e é exatamente nessa discordância que vive o request smuggling.

## O que o HTTP deixa para os outros

O HTTP é stateless de propósito: cada requisição vale por si, e o servidor não tem obrigação nenhuma de lembrar da anterior. O estado foi acrescentado por cima. O servidor grava um cookie com o header Set-Cookie, e o navegador o devolve com o header Cookie, nas requisições que o escopo do cookie permite (RFC 6265).

O caminho também raramente é direto. "HTTP enables the use of intermediaries to satisfy requests through a chain of connections", e o padrão cita três formas comuns desses intermediários: proxy, gateway e túnel (RFC 9110, seção 3.7). Quase tudo o que um operador mantém entre o navegador e o servidor é um deles, seja um forward proxy na borda do escritório, seja um reverse proxy na frente dos servidores, e cada um lê, e pode reescrever, as mensagens que repassa.

## O método mais novo

A lista de métodos cresceu em junho de 2026. A RFC 10008 define o QUERY: "As with POST, the input to the query operation is passed as the content of the request rather than as part of the request URI"; mesmo assim, "QUERY requests are safe with regard to the target resource" e "QUERY requests are idempotent". Na prática, uma busca grande demais para caber num endereço agora pode ir no corpo da requisição e, ainda assim, ser repetida e ter a resposta guardada em cache, como acontece com um GET.

## Esta série, em ordem

Dez partes: a mensagem lida de cima para baixo, depois as camadas em volta dela e, por fim, um epílogo.

1. **[Requisição HTTP crua: como ler e transformar de volta em algo que roda](https://ronutz.com/pt-BR/learn/raw-http-requests-and-how-to-replay-them)**. A mensagem como ela chega de verdade, com linha de requisição, campos e corpo, e as três armadilhas na hora de reproduzi-la.
2. **[Métodos HTTP: os verbos da web](https://ronutz.com/pt-BR/learn/http-methods-the-verbs)**. A primeira palavra da linha de requisição e as duas propriedades, safe (segura) e idempotente, que caches, retries e crawlers levam em conta para agir.
3. **[Códigos de status HTTP: as cinco famílias](https://ronutz.com/pt-BR/learn/http-status-codes-the-five-families)**. O primeiro dígito da resposta já diz quase tudo; depois vêm os códigos que um operador encontra de fato.
4. **[Headers HTTP: a anatomia dos metadados](https://ronutz.com/pt-BR/learn/http-headers-anatomy)**. Os campos que as duas mensagens carregam: os quatro papéis que eles cumprem, o campo Host e a divisão entre fim a fim (end-to-end) e hop by hop.
5. **[Cookies HTTP: estado sobre um protocolo sem estado](https://ronutz.com/pt-BR/learn/http-cookies-state-over-stateless)**. Dois campos de header que dão memória a um protocolo stateless, e as regras que dizem quando o cookie vai junto.
6. **[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)**. A camada de framing: como o receptor sabe onde uma mensagem acaba e a próxima começa, e o que o smuggling explora.
7. **[Proxies HTTP: forward ou reverse, explícito ou transparente](https://ronutz.com/pt-BR/learn/http-proxy-forward-and-reverse)**. Os intermediários: para qual lado o proxy trabalha, se o cliente sabe que ele está ali e os campos que registram a passagem dele.
8. **[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)**. Os mesmos significados transportados de cinco formas, de um GET de uma linha só a streams multiplexados sobre QUIC.
9. **[HTTP QUERY: a leitura que finalmente carrega um corpo](https://ronutz.com/pt-BR/learn/http-query-method)**. O método mais novo: o que ele resolve, como as respostas dele vão para o cache e o que cada camada da infraestrutura precisa verificar.
10. **[Mensagens escondidas em headers HTTP: homenagens, piadas e vagas de emprego no overhead](https://ronutz.com/pt-BR/learn/hidden-messages-in-http-headers)**. Um epílogo: o que as pessoas escreveram nos campos que quase ninguém lê.

## Fontes

- [RFC 9110, HTTP Semantics (STD 97), junho de 2022: o resumo (os aspectos "shared by all versions"), a seção 3.4 (um protocolo de requisição e resposta sem estado) e a seção 3.7 (intermediários: proxy, gateway, túnel) (lida em 2026-10-07)](https://www.rfc-editor.org/rfc/rfc9110)
- [RFC 9112, HTTP/1.1 (STD 99), junho de 2022: a sintaxe e o enquadramento das mensagens da versão 1.1 (lida em 2026-10-06)](https://www.rfc-editor.org/rfc/rfc9112)
- [RFC 9113, HTTP/2, junho de 2022: "an optimized expression of the semantics" do HTTP; torna obsoletas a RFC 7540 e a RFC 8740 (lida em 2026-10-06)](https://www.rfc-editor.org/rfc/rfc9113)
- [RFC 9114, HTTP/3, junho de 2022: o HTTP sobre o transporte QUIC (lida em 2026-10-06)](https://www.rfc-editor.org/rfc/rfc9114)
- [RFC 6265, HTTP State Management Mechanism, abril de 2011: os campos de cabeçalho Cookie e Set-Cookie (lida em 2026-10-06)](https://www.rfc-editor.org/rfc/rfc6265)
- [RFC 10008, The HTTP QUERY Method, junho de 2026: a seção 1 (a consulta passada como conteúdo da requisição), a seção 2 (segura e idempotente) e a seção 2.7 (a resposta pode ir para o cache) (lida em 2026-10-06)](https://www.rfc-editor.org/rfc/rfc10008)