RFC 9111 §3.1
requires fields specific to the proxy used by a cache to be excluded from
storage unless the cache key includes the proxy identity. However, that
requirement names only header fields, while the same section permits trailer
fields to be stored separately from header fields (or discarded).
RFC 9110 §11.7.3
permits Proxy-Authentication-Info in a trailer when the authentication scheme
explicitly allows it. As written, the RFC 9111 storage restriction applies when
that field is in the header section but not when it is in the trailer section.
The review history appears relevant. In
PR #337,
Roy Fielding wrote: "The first MUST is right, but I believe the last three cases
apply to both header and trailer fields." He then illustrated the point with
Connection-named fields and trailers being forwarded. In
commit c9ba2639, the
first two bullets were generalized from header fields to fields. In the third,
new header fields was changed to new fields, but the opening remained
limited to Header fields. In
commit 67af3e3b, that
third bullet was rewritten around a client's proxy configuration and
Proxy-Authentication-Info was added, while the opening still named only header
fields. In
commit 3de99085,
titled "Address Roy's concern", the first two bullets were revised again while
the third was left unchanged. The pull request was merged on 2020-05-25.
To check current practical reachability, I reviewed the specifications cited by
all 14 entries in the current
IANA HTTP Authentication Scheme Registry.
I found no scheme that unambiguously permits Proxy-Authentication-Info itself
in a trailer. Digest's RFC 7616 §3.5 heading covers both Authentication-Info
and Proxy-Authentication-Info, but its trailer-permission sentence explicitly
names only Authentication-Info. The Experimental Mutual scheme in RFC 8120
prohibits the corresponding trailer use. I therefore have no evidence of a
current implementation or security impact; this issue concerns the textual
scope and its review history.
Could you confirm whether the remaining limitation to header fields was
intentional? If not, a future revision could clarify that the proxy-specific
storage restriction applies to fields in both the header and trailer sections.
RFC 9111 §3.1
requires fields specific to the proxy used by a cache to be excluded from
storage unless the cache key includes the proxy identity. However, that
requirement names only header fields, while the same section permits trailer
fields to be stored separately from header fields (or discarded).
RFC 9110 §11.7.3
permits Proxy-Authentication-Info in a trailer when the authentication scheme
explicitly allows it. As written, the RFC 9111 storage restriction applies when
that field is in the header section but not when it is in the trailer section.
The review history appears relevant. In
PR #337,
Roy Fielding wrote: "The first MUST is right, but I believe the last three cases
apply to both header and trailer fields." He then illustrated the point with
Connection-named fields and trailers being forwarded. In
commit
c9ba2639, thefirst two bullets were generalized from header fields to fields. In the third,
new header fieldswas changed tonew fields, but the opening remainedlimited to
Header fields. Incommit
67af3e3b, thatthird bullet was rewritten around a client's proxy configuration and
Proxy-Authentication-Info was added, while the opening still named only header
fields. In
commit
3de99085,titled "Address Roy's concern", the first two bullets were revised again while
the third was left unchanged. The pull request was merged on 2020-05-25.
To check current practical reachability, I reviewed the specifications cited by
all 14 entries in the current
IANA HTTP Authentication Scheme Registry.
I found no scheme that unambiguously permits Proxy-Authentication-Info itself
in a trailer. Digest's RFC 7616 §3.5 heading covers both Authentication-Info
and Proxy-Authentication-Info, but its trailer-permission sentence explicitly
names only Authentication-Info. The Experimental Mutual scheme in RFC 8120
prohibits the corresponding trailer use. I therefore have no evidence of a
current implementation or security impact; this issue concerns the textual
scope and its review history.
Could you confirm whether the remaining limitation to header fields was
intentional? If not, a future revision could clarify that the proxy-specific
storage restriction applies to fields in both the header and trailer sections.