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

From: Julian Reschke <[email-masked]>
Date: Sun, 28 Jul 2013 13:07:43 +0200

On 2013-05-07 07:19, Mark Nottingham wrote:
> OK, assigning for -23 with an editorial change to P1 to note the difference from 2616 (e.g., in "Changes from RFC2616").

In -21, we removed the concept of implicit hop-by-hop altogether; and 
this is mentioned already:

"Clarify exactly when "close" connection options have to be sent; drop 
notion of header fields being "hop-by-hop" without being listed in the 
Connection header field. (Section 6.1)" -- 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-21.html#rfc.section.A.2.p.9>

Do we really need to mention Proxy-* explicitly?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 29 Jul 2013 14:31:40 +0200

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.

… 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.

Cheers,

On Jul 28, 2013, at 1:07 PM, Julian Reschke <[email-masked]> wrote:

> In -21, we removed the concept of implicit hop-by-hop altogether; and this is mentioned already:
> 
> "Clarify exactly when "close" connection options have to be sent; drop notion of header fields being "hop-by-hop" without being listed in the Connection header field. (Section 6.1)" -- <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-21.html#rfc.section.A.2.p.9>
> 

--
Mark Nottingham   http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Mon, 29 Jul 2013 15:30:53 +0200

>> 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…

Out of curiosity: why does the "SHOULD NOT" show up as "should not"?

> 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.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 29 Jul 2013 15:39:35 +0200

> 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.

>  "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."
> 

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?

---

From: Julian Reschke <[email-masked]>
Date: Mon, 29 Jul 2013 15:46:41 +0200

> 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 changes for Proxy-Authorization.

Sounds good.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 29 Jul 2013 16:33:50 +0200

On 2013-07-29 15:46, Julian Reschke wrote:
>>>>> 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.
>>>
>>>> … with similar text for Proxy-Authorization. The "SHOULD NOT
>>>> forward…" requirement is in conflict with the sentiment expressed
>>>> above.
>>>>
>>>   "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."
>>>
>> "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."
>>

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

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 29 Jul 2013 16:49:24 +0200

/me re-reads; yep, looks good.

Thanks,

On Jul 29, 2013, at 4:33 PM, Julian Reschke <[email-masked]> wrote:

> Proposed patch for Proxy-Authenticate: <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/473/473.diff>
> 
> "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."
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 29 Jul 2013 17:01:48 +0200

On 2013-07-29 16:49, Mark Nottingham wrote:
> ...

-> <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2322>

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 30 Jul 2013 08:35:27 +1200

> /me re-reads; yep, looks good.

Ditto. +1.

Amos