Especificação RFC 9110

1. Definição e Contexto Histórico

A RFC 9110, publicada em junho de 2022, sob o título "HTTP Semantics", é o documento normativo que consolidou a semântica do HTTP em uma única referência canônica. Ela substituiu formalmente os documentos legados RFC 2616 (HTTP/1.1 de 1999) e a família RFC 723x (HTTP/1.1 revisado em 2014). A RFC 9110 desacopla a semântica HTTP (métodos, status codes, cabeçalhos) dos mecanismos de transporte (HTTP/1.1, HTTP/2, HTTP/3), permitindo que a semântica evolua independentemente da versão do protocolo utilizada no fio.

2. A Revolução do HTTP/1.1: Histórico da RFC 2616

Antes da RFC 2616 (1999), o HTTP/1.0 era extremamente ineficiente, abrindo e fechando uma conexão TCP para cada imagem ou script de uma página.

• Conexões Persistentes (Persistent Connections): A maior inovação da 2616 foi tornar o mecanismo de "Manter-se Vivo" (Keep-Alive) o comportamento padrão. Isso permitiu que múltiplos recursos fossem transmitidos em uma única conexão TCP, reduzindo drasticamente o overhead de handshakes e a latência percebida pelo usuário final.
• Pipelining: Introduziu a capacidade teórica de enviar múltiplas requisições sem esperar pela resposta da anterior (embora com limitações de implementação em navegadores, posteriormente substituído pelo multiplexing da RFC 7540).

Linha do Tempo das RFCs HTTP

3. Inovações em Transferência e Controle de Cache

A semântica HTTP introduziu mecanismos sofisticados para lidar com grandes volumes de dados e otimização de banda.

• Codificação de Transferência Fragmentada (Chunked Transfer Encoding): Permite que servidores comecem a enviar dados antes mesmo de saber o tamanho total do recurso, ideal para conteúdos gerados dinamicamente (PHP, Node.js streams).
• Cache-Control: Cabeçalho abrangente que permite políticas granulares de expiração (max-age, s-maxage), revalidação (must-revalidate, proxy-revalidate) e visibilidade (private, public, no-cache, no-store).

Cabeçalhos Semânticos Padronizados pela RFC 9110

4. Anatomia da Mensagem HTTP (Sintaxe e Semântica)

A RFC fixou a estrutura rígida de uma mensagem HTTP, composta por quatro partes essenciais:

1. Linha de Início (Start-line): Define o método, a URI e a versão do protocolo (ex: GET /index.html HTTP/1.1). Em respostas, contém status code e reason phrase.
2. Campos de Cabeçalho (Headers): Conjuntos de chave-valor que fornecem metadados sobre a mensagem (ex: Host, User-Agent, Content-Type).
3. Linha Vazia: Um separador compulsório (CRLF) que indica o fim dos cabeçalhos.
4. Corpo da Mensagem (Body): Onde os dados reais (HTML, imagem, JSON) são transportados.

Exemplo de Requisição HTTP/1.1

POST /api/v1/login HTTP/1.1
Host: api.empresa.com
User-Agent: Mozilla/5.0
Content-Type: application/json
Content-Length: 47
Accept: application/json

{"username":"admin","password":"secret"}

Exemplo de Resposta HTTP/1.1

HTTP/1.1 200 OK
Date: Mon, 15 Jan 2025 10:00:00 GMT
Content-Type: application/json
Content-Length: 92
Cache-Control: private, max-age=0
ETag: "abc123"

{"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6...","expires":3600}

5. Categorias de Métodos HTTP Definidos

6. Status Codes Padronizados (Resumo por Classe)

7. Perspectiva de Cyber Security e Conformidade Normativa

Para o auditor de Cyber Security, a conformidade com a RFC 9110 é o primeiro passo para o "Hardening" de um servidor web.

Ambiguidade e Ataques de Smuggling

A má interpretação de como os campos Content-Length e Transfer-Encoding devem interagir era a causa raiz de ataques onde um invasor "contrabandeia" requisições maliciosas através de proxies reversos.

• O Risco: Se o Frontend interpreta um cabeçalho e o Backend outro, o atacante pode envenenar o cache do servidor ou sequestrar sessões de outros usuários legítimos de forma totalmente invisível.
• Mitigação RFC 9110: A nova RFC proíbe explicitamente o uso simultâneo de ambos os cabeçalhos, determinando que servidores devem rejeitar a requisição com erro 400.

Strict Transport Security (HSTS)

A RFC 9110 reforça o uso de HSTS para prevenir downgrade attacks. Cabeçalho Strict-Transport-Security: max-age=31536000; includeSubDomains; preload.

Cookies e SameSite

Embora cookies sejam definidos por RFC separadas (6265bis), a RFC 9110 estabelece o contexto semântico para Set-Cookie como um cabeçalho de controle de estado.

8. Diagnóstico de Conformidade

Testar a resposta bruta de um servidor é a única forma de validar o cumprimento das normas sem interferências:

# Realizando uma requisição HTTP/1.1 manual com cabeçalho Host obrigatório
telnet servidor.com 80
GET / HTTP/1.1
Host: servidor.com

# Inspecionando a resposta do servidor para validar o uso de Chunked Encoding
curl -v -o /dev/null http://www.google.com 2>&1 | grep -i "transfer-encoding"

# Verificando se o servidor rejeita Content-Length + Transfer-Encoding juntos
printf 'POST / HTTP/1.1\r\nHost: alvo\r\nContent-Length: 4\r\nTransfer-Encoding: chunked\r\n\r\n0\r\n\r\n' | nc alvo 80

# Listando métodos suportados via OPTIONS
curl -X OPTIONS -v http://api.empresa.com/

# Validando suporte a HTTP/2 via ALPN
curl --http2 -I https://www.cloudflare.com

Análise do Cabeçalho Host: A RFC 2616 tornou o cabeçalho Host obrigatório. Sem ele, o servidor deve retornar um erro 400 Bad Request. Isso permitiu a proliferação da Hospedagem Virtual (Virtual Hosting), onde milhares de domínios podem coexistir sob um único endereço IP.

9. Conclusão: O Manuscrito Sagrado do Webmaster

A RFC 9110 é mais do que um documento técnico; é o contrato social que permitiu à web escalar de uma curiosidade acadêmica para uma necessidade existencial moderna. Embora o HTTP/2 e o HTTP/3 tragam performance superior no transporte, as bases semânticas da RFC 9110 ainda constituem o núcleo duro de como a informação é solicitada e entregue em todo o planeta. Dominar sua sintaxe, compreender suas regras de persistência e cache, e aplicar suas diretrizes de segurança garante que infraestruturas web permaneçam compatíveis, interoperáveis e resilientes frente às ameaças modernas.