LEARN. PRACTICE. GROW.Concept and mechanism
A protocol needs to identify where each message ends. In HTTP/1.1, Content-Length and Transfer-Encoding participate in framing under specific rules. A sender must not send both; differing interpretations between proxy and backend can desynchronize requests. Handle the case under protocol error, forwarding, and closing rules while also correcting the sender. Do not assume every parser rejects in exactly the same way. For a GET response declaring 1200 bytes without Transfer-Encoding, receiving only 900 before closure means an incomplete response. The initial 200 status does not turn missing bytes into a valid result.
Guided application
Method and status matter: HEAD carries no response body while allowing the size of the corresponding GET representation. Do not mechanically apply truncation diagnosis to that case. HTTP/2 introduces multiplexing and binary framing over TCP, but ordered transport delivery can still block streams when loss occurs. HTTP/3 uses QUIC over UDP and provides independent streams, requiring support checks across client, server, and path. This promises neither zero latency nor removal of congestion controls. In a migration exercise, compare negotiated versions, equivalent requests, and failure patterns before attributing improvement or regression to the version number. Keep functional criteria constant during comparison.
GET with 1200 declared bytes and 900 received is incomplete; HEAD without a body can be correct.
Common pitfalls
Counting characters as bytes; ignoring HEAD exceptions; tolerating conflicting boundaries; HTTP/2 as the end of all blocking.
Related topics: The request and intended representation · Methods, statuses, and controlled retries · Caching, variants, and validation
Interpret framing in the exact version and request context.
Reference: HTTP/1.1 framing · DR HTTP/HTTPS 2026-09; HTTP RFCs 9110–9114; selected TLS 1.3 and NGINX/curl guidance