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

[Julian Reschke <[e-mail]>]

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