Limit disclosure and trust
05Diagnostics can expose backend topology or sensitive deployment details. A readable Proxy-Status report is a claim by an intermediary, not independent proof.
No Proxy-Status is visible. Optional generation, explicit removal or dropped trailers can explain absence; it does not establish success or absence of intermediaries.
Source for this drawing: RFC 9209 · Read RFC section 4 ↗
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 field and every parameter are optional. A deployment can conditionally disclose information only to authorised parties; this RFC does not require diagnostic fields on every response.
- The field and every parameter are optional. A deployment can conditionally disclose information only to authorised parties; this RFC does not require diagnostic fields on every response.
- Configuration and backend details can aid attackers. Choose which members and parameters to reveal; §2 allows explicit configuration to remove earlier members.
- The content is not verified. A proxy can claim an action it did not perform. A protocol identifier alone is not evidence of encryption, authentication or actual negotiation.
All names and values are fictional. Do not use diagnostic details as trusted instructions or automatically authorise access or retries based on an unverified report. This guide adds no account or telemetry behaviour.
Read the RFC section ↗