1xx - Informativo

1. Definição e Características

A classe de status HTTP 1xx Informational é definida pela RFC 7231 (seção 6.2) como a classe de respostas provisórias enviadas antes da resposta final. Indicam que o servidor recebeu a requisição e está processando, mas ainda não tem uma resposta definitiva. São respostas intermediárias; o cliente deve aguardar a resposta final subsequente.

• Faixa numérica: 100 a 199
• Cliente deve aguardar resposta final: Sim
• Possui corpo: Não (na maioria dos casos)
• Cacheável: Não
• RFC de referência: RFC 7231 §6.2 (obsoleta por RFC 9110)

Códigos 1xx Padronizados

2. 100 Continue

100 Continue é enviado em resposta ao header Expect: 100-continue na requisição. Indica que o cliente pode enviar o corpo da requisição. O propósito é evitar que o cliente envie um corpo grande (ex: upload de arquivo) que o servidor rejeitaria antes de ler.

POST /upload HTTP/1.1
Host: api.exemplo.com
Content-Length: 10485760
Expect: 100-continue
Content-Type: application/octet-stream

HTTP/1.1 100 Continue
# (cliente envia 10 MB)

HTTP/1.1 201 Created
Location: /files/abc123

Se o servidor for rejeitar a requisição (ex: arquivo muito grande), responde com erro final em vez de 100 Continue: 413 Payload Too Large. Nesse caso, o cliente não envia o corpo, economizando banda.

Comportamento de Clientes

• curl: envia Expect: 100-continue automaticamente para corpos > 1 KB. Aguarda 1 segundo por 100 Continue antes de enviar o corpo (evita deadlocks se servidor não suporta).
• Browsers: tipicamente não usam Expect: 100-continue; enviam o corpo imediatamente.
• HTTP/2 e HTTP/3: não usam Expect; o mecanismo é específico do HTTP/1.1.

Boas Práticas

Em APIs que aceitam uploads grandes (vídeos, imagens de alta resolução), configurar o servidor para responder 100 Continue antes de o cliente iniciar o upload reduz desperdício de banda em requisições que seriam rejeitadas.

3. 101 Switching Protocols

101 Switching Protocols é enviado em resposta ao header Upgrade. Indica que o servidor concordou em mudar o protocolo da conexão atual para o especificado no header Upgrade da resposta.

GET /chat HTTP/1.1
Host: chat.exemplo.com
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

A partir desse momento, a conexão TCP deixa de falar HTTP/1.1 e passa a falar WebSocket.

Casos de Uso

O upgrade só funciona em HTTP/1.1. Em HTTP/2 e HTTP/3, usa-se mecanismos próprios (SETTINGS frame, EXTENDED CONNECT). Após o upgrade, a semântica HTTP não se aplica mais na conexão. Nem todos os servidores/proxies suportam upgrade; intermediários podem fechar a conexão.

4. 102 Processing (WebDAV)

102 Processing é definido pela RFC 4918 (WebDAV). É enviado periodicamente pelo servidor quando uma operação WebDAV está demorando mais que alguns segundos, para evitar timeout do cliente. Não é resposta final; o cliente deve continuar aguardando.

PROPFIND /documents/ HTTP/1.1
Host: webdav.exemplo.com
Depth: 1

HTTP/1.1 102 Processing   # (intermediária)
HTTP/1.1 207 Multi-Status # (final)

Aplicável apenas a operações WebDAV (PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK). Não usado por APIs REST comuns; clientes tradicionais (curl, browsers) podem não expor respostas intermediárias.

5. 103 Early Hints

103 Early Hints (RFC 8297) permite que o servidor envie hints sobre recursos que o cliente deve pré-carregar antes de a resposta final estar pronta. Reduz latência percebida ao permitir que o navegador inicie fetch de CSS, JS e fontes enquanto o servidor ainda gera a página.

HTTP/1.1 103 Early Hints
Link: </styles.css>; rel=preload; as=style
Link: </app.js>; rel=preload; as=script
Link: </fonts/roboto.woff2>; rel=preload; as=font; crossorigin

HTTP/1.1 200 OK
Content-Type: text/html
...

O navegador recebe 103 e inicia o fetch de styles.css, app.js e roboto.woff2 em paralelo, antes de receber o HTML final. Quando o HTML chega, os recursos já estão sendo baixados.

Benefícios e Suporte

• Reduz latência percebida em 200-500 ms em páginas com múltiplos assets críticos.
• Funciona com HTTP/1.1, HTTP/2 e HTTP/3.
• Compatível com preload, preconnect, dns-prefetch.
• Chrome 103+ (2022), Firefox 99+ suportam 103 Early Hints.
• Servidores: Nginx 1.13.9+, Cloudflare (Early Hints), H2O.
• Intermediários (proxies) devem preservar respostas 1xx; alguns podem quebrar.

Considerações

• O servidor deve enviar 103 antes de começar a processar a resposta final. Requer framework que suporte streaming.
• Recursos em 103 devem ser idempotentes (não devem disparar side-effects no servidor).
• Se o servidor já enviou 103 com Link, deve repetir o mesmo Link na resposta final.

6. Headers Importantes

• Expect (cliente→servidor): Expect: 100-continue.
• Upgrade (bidirecional): Cliente envia Upgrade: websocket + Connection: Upgrade; servidor responde 101 Switching Protocols + Upgrade: websocket + Connection: Upgrade.
• Link (103 Early Hints): Link: </styles.css>; rel=preload; as=style.

7. Comparativo de Respostas 1xx

8. Exemplos Práticos

curl com Expect: 100-continue

curl -v -X POST https://api.exemplo.com/upload \
  -H "Content-Type: application/octet-stream" \
  --data-binary @arquivo_grande.bin
# > Expect: 100-continue
# < HTTP/1.1 100 Continue
# < HTTP/1.1 201 Created

curl com Upgrade WebSocket

curl -v --include -H "Connection: Upgrade" -H "Upgrade: websocket" \
  -H "Sec-WebSocket-Version: 13" \
  -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
  https://chat.exemplo.com/ws
# < HTTP/1.1 101 Switching Protocols
# < Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Nginx — Early Hints

location / {
    add_header Link "</styles.css>; rel=preload; as=style" always;
    proxy_pass http://backend;
}

9. Boas Práticas

• Suportar 100 Continue em uploads: Servidores que aceitam uploads grandes devem responder 100 Continue rapidamente. Configurar timeout curto (1s) para resposta 100 evita deadlocks com clientes que não implementam Expect.
• Não intermediar 1xx em proxies: Proxies devem encaminhar respostas 1xx imediatamente ao cliente. Algumas implementações antigas as descartam, quebrando 101 Switching Protocols.
• Validar 103 Early Hints em CDN: CDNs que reescrevem ou reordenam respostas podem corromper 103 Early Hints. Validar comportamento com Cloudflare ou Akamai antes de deploy.
• Evitar 102 Processing em APIs REST: 102 Processing é específico de WebDAV. Em APIs REST, prefira 202 Accepted com job ID para operações longas assíncronas.

10. Resumo Técnico

11. Conclusão

A classe 1xx é a menos visível das classes HTTP, mas tem papel crítico em otimizações modernas. 100 Continue reduz desperdício de banda em uploads, 101 Switching Protocols habilita WebSocket, 102 Processing previne timeouts em operações WebDAV longas, e 103 Early Hints reduz latência percebida ao permitir preload paralelo de assets críticos. O suporte a essas respostas intermediárias — tanto por servidores quanto por intermediários (proxies, CDNs) — é essencial para arquiteturas web performáticas. Engenheiros que trabalham com uploads, real-time e otimização de carregamento devem conhecer profundamente os mecanismos de cada código 1xx.