APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Um protocolo precisa de identificar onde termina cada mensagem. Em HTTP/1.1, Content-Length e Transfer-Encoding participam nessa delimitação, com regras específicas. Um emissor não deve enviar ambos; interpretações divergentes entre proxy e backend podem dessincronizar pedidos. Trata o caso segundo as regras de erro, encaminhamento e fecho do protocolo, corrigindo também o emissor. Não assumes que todos os parsers rejeitam exatamente da mesma forma. Numa resposta GET com comprimento explícito de 1200 bytes e sem Transfer-Encoding, receber apenas 900 antes do fecho significa resposta incompleta. O estado 200 inicial não transforma os bytes em falta num resultado válido.
Aplicação guiada
O método e o estado importam: HEAD não transporta corpo de resposta, podendo indicar o tamanho da representação correspondente a GET. Não apliques mecanicamente o diagnóstico de truncagem a esse caso. HTTP/2 introduz multiplexagem e framing binário sobre TCP, mas a entrega ordenada do transporte ainda pode bloquear streams quando há perda. HTTP/3 usa QUIC sobre UDP e oferece streams independentes, exigindo confirmar suporte no cliente, servidor e percurso. Isso não promete latência zero nem elimina controlos de congestionamento. Num exercício de migração, compara versões negociadas, pedidos equivalentes e padrões de falha antes de atribuir melhoria ou regressão ao número da versão. Mantém critérios funcionais constantes na comparação.
GET com 1200 bytes declarados e 900 recebidos é incompleto; HEAD sem corpo pode estar correto.
Armadilhas comuns
Contar caracteres como bytes; ignorar exceções de HEAD; tolerar limites contraditórios; HTTP/2 como fim de todo o bloqueio.
Tópicos relacionados: O pedido e a representação pretendida · Métodos, estados e repetição controlada · Cache, variantes e validação
Interpreta framing na versão e no contexto exatos do pedido.
Referência: HTTP/1.1 framing · DR HTTP/HTTPS 2026-09; HTTP RFCs 9110–9114; selected TLS 1.3 and NGINX/curl guidance