Locate the failure
03An error parameter describes an intermediary’s problem obtaining the response. Some errors require a proxy-generated response; others can accompany an origin’s partial response.
In a third case, an origin’s 200 and partial content have already passed through. The connection then closes. connection_terminated can be reported late; the already-sent 200 cannot simply be rewritten.
Source for this drawing: RFC 9209 · Read RFC section 2.1.1 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
The most specific accurately applicable error type SHOULD be used. DNS timeout and connection timeout identify different failed stages.
- The most specific accurately applicable error type SHOULD be used. DNS timeout and connection timeout identify different failed stages.
- When generating a response containing an error, its HTTP status SHOULD use the registered recommendation; circumstances such as already-sent status can justify another code.
- dns_timeout and connection_timeout have recommended 504 and require proxy-generated responses. connection_terminated recommends 502 but can also describe a response that began upstream.
These are three alternative cases, not consecutive failures of one exchange. Registered recommendations are SHOULD, not unconditional MUST. The publication defines 32 initial error types and extensible registries (§§2.2–2.4); this chapter illustrates selected types rather than implying only these exist.
Read the RFC section ↗