Re: #473, was: p7: forwarding Proxy-*

[Mark Nottingham <[e-mail]>]

/me re-reads; yep, looks good.

Thanks,


On Jul 29, 2013, at 4:33 PM, Julian Reschke <[e-mail]> 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 <[e-mail]>
>>> 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/