Follow the response path
01A proxy is an intermediary: it handles HTTP between a client and the next server. Proxy-Status records response handling in a structured list.
Edge preserves Inner and appends its own member. The client sees Inner, Edge: origin-side first, client-side last.
Source for this drawing: RFC 9209 · Read RFC section 2 ↗
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 first list member is closest to the origin; the last is closest to the user agent. This is response-path order, not request-path order.
- The first list member is closest to the origin; the last is closest to the user agent. This is response-path order, not request-path order.
- Members MUST be Strings or Tokens identifying a deployment, such as a service alias or hostname; a product name alone is insufficient.
- Origin servers MUST NOT generate Proxy-Status. Intermediaries choose whether to add it and SHOULD preserve existing members unless explicitly configured to remove them.
Aliases Inner and Edge are fictional deployments. Missing members do not prove that a request bypassed other proxies. The list is not a verified network trace.
Read the RFC section ↗