- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 29 Jul 2013 16:33:50 +0200
- To: Mark Nottingham <mnot@mnot.net>
- CC: "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 2013-07-29 15:46, Julian Reschke wrote: > On 2013-07-29 15:39, Mark Nottingham wrote: >> >> On Jul 29, 2013, at 3:30 PM, Julian Reschke <julian.reschke@gmx.de> >> wrote: >> >>> On 2013-07-29 14:31, Mark Nottingham wrote: >>>> The conclusion of the conversation was Roy's statement: >>>> >>>>> No, I am just saying that Connection is not required; if it is not >>>>> included in Connection, then the intention is that it be forwarded >>>>> until consumed. OTOH, if it is included in Connection, then it >>>>> will be consumed or deleted by the immediate recipient. AFAIK, >>>>> these fields are not normally included in Connection, but there >>>>> might be a good reason to if the proxy selection is complicated. >>>> >>>> Which seems reasonable and no one has objected. However, p7 still says: >>>> >>>>> Unlike WWW-Authenticate, the Proxy-Authenticate header field >>>>> applies only to the current connection, and intermediaries should >>>>> not forward it to downstream clients. However, an intermediate >>>>> proxy might need to obtain its own credentials by requesting them >>>>> from the downstream client, which in some circumstances will appear >>>>> as if the proxy is forwarding the Proxy-Authenticate header field. >>> >>> Out of curiosity: why does the "SHOULD NOT" show up as "should not"? >> >> Cut and paste of the HTML in Safari loses the uppercasing applied by >> the stylesheet, I think. > > If you look at the raw HTML; you'll see it has "SHOULD NOT" (exactly so > that copy&paste does the expected thing). Bad Safari. > >>>> … with similar text for Proxy-Authorization. The "SHOULD NOT >>>> forward…" requirement is in conflict with the sentiment expressed >>>> above. >>>> >>>> I've changed the target to p7. >>> >>> OK. >>> >>> So maybe change >>> >>> "Unlike WWW-Authenticate, the Proxy-Authenticate header field >>> applies only to the current connection, and intermediaries SHOULD NOT >>> forward it to downstream clients." >>> >>> to >>> >>> "Unlike WWW-Authenticate, the Proxy-Authenticate header field >>> applies only to the current connection, and *proxies* SHOULD NOT >>> forward it to downstream clients." >>> >>> This would allow non-proxy intermediaries to forward it. >>> >> >> I think we need to make it a more discretionary thing; e.g., >> >> "Unlike WWW-Authenticate, the Proxy-Authenticate header field usually >> applies to the current connection, and proxies generally will consume >> it, rather than forwarding it to downstream clients." >> >> With similar changes for Proxy-Authorization. >> >> Make sense? > > Sounds good. > > Best regards, Julian Proposed patch for Proxy-Authenticate: <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/473/473.diff> Looking at Proxy-Authorization: "Unlike Authorization, the Proxy-Authorization header field applies only to the next outbound proxy that demanded authentication using the Proxy-Authenticate field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed by the first outbound proxy that was expecting to receive credentials. A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request." ...which seems to be correct already, right? Best regards, Julian
Received on Monday, 29 July 2013 14:34:25 UTC