- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 29 Jul 2013 16:49:24 +0200
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
/me re-reads; yep, looks good. Thanks, On Jul 29, 2013, at 4:33 PM, Julian Reschke <julian.reschke@gmx.de> wrote: > 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 > -- Mark Nottingham http://www.mnot.net/
Received on Monday, 29 July 2013 14:49:46 UTC