Keep proxy information on its response hop
04Proxy-Authentication-Info concerns authentication to a proxy and normally applies to the next client on the response chain.
Independent configured example: office and regional proxies share the relevant authentication arrangement. Each sends the same field value toward its own next client; this can look like forwarding.
Source for this drawing: RFC 7615 · Read RFC section 4 ↗
New to this? Start hereA quick picture + helpful background
A request starts a conversation.
A client asks for a resource. A server sends a response. The method, address, headers, and status explain what that conversation means.
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
This guide explains the 2015 publication. Superseded by RFC 9110.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Its semantics come from Proxy-Authorization in the corresponding request, not from the origin Authorization scheme.
- Its semantics come from Proxy-Authorization in the corresponding request, not from the origin Authorization scheme.
- The next outbound client on the response chain can itself be another proxy. This is not an instruction to send proxy credentials to the origin.
- Within one administrative domain, a credential-sharing proxy hierarchy can appear to forward this field because each proxy sends the same value. This scoped case does not make arbitrary end-to-end forwarding the general rule.
No authentication scheme, shared-credential policy or proxy deployment is implemented. Origin Authentication-Info and proxy information can coexist but retain different request contexts. The hierarchy example is conditional, not a universal permission to propagate credentials.
Read the RFC section ↗