Forward origin information unchanged
03An intermediary may carry an origin response without becoming the authority for its Authentication-Info value.
A separate attempted change to note=changed is forbidden while forwarding. The stopped path does not depict successful delivery of the rewritten value.
Source for this drawing: RFC 7615 · Read RFC section 3 ↗
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.
A proxy forwarding a response is not allowed to modify the Authentication-Info field value in any way.
- A proxy forwarding a response is not allowed to modify the Authentication-Info field value in any way.
- A proxy’s own authentication information uses Proxy-Authentication-Info and has separate scope; it must not replace the origin field’s value.
- A syntactically readable value still needs the matching request scheme and its checks. Forwarding unchanged does not make an untrusted origin trusted.
The diagram separates the origin, forwarding proxy and client. It depicts the field value, not HTTP/2 compression, whitespace serialization elsewhere in the message, end-to-end encryption or all intermediary behavior.
Read the RFC section ↗