Subject: Re: New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt

From: Julian Reschke <[email-masked]>
Date: Fri, 10 Nov 2017 08:52:51 +0100

On 2017-10-15 20:39, Patrick McManus wrote:
> 
> 
> On Sun, Oct 15, 2017 at 11:43 AM, Cory Benfield <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Doesn’t the introduction of a new pseudo-header field violate RFC
>     7540 Section 8.1.2.1, which says endpoints MUST NOT generate new
>     pseudo-header fields?
> 
>     Or is the position that that MUST NOT implicitly applies only if
>     there are no negotiated extensions in use?
> 
> 
> right - negotiating an extension via 7540 section 5.5 is an opt-in 
> procedure that lets you do just about anything you agree to.. the spec 
> tries to draw a bright line between extensions that can be ignored 
> safely and those that cannot and need to be negotiated (such as this 
> one). Enjoy the example in there about changing the layout of the 
> HEADERS frame :). This is also why extensions are hop to hop.
> 
> one of the reasons I chose the pseudo header to only apply to CONNECT is 
> already very special purpose - so the exception doesn't pollute very far 
> as a practical matter.
> ...

But still, it leaks. What if a different extension that wants to 
co-exist with this one wants to define a pseudo header field with the 
same name?

Best regards, Julian

---

From: Kari Hurtta <[email-masked]>
Date: Sat, 11 Nov 2017 23:07:18 +0200 (EET)

>> Doesn’t the introduction of a new pseudo-header field violate RFC 7540
>> Section 8.1.2.1, which says endpoints MUST NOT generate new pseudo-header
>> fields?
>>
>> Or is the position that that MUST NOT implicitly applies only if there are
>> no negotiated extensions in use?
>>
>>
>procedure that lets you do just about anything you agree to..

I note that new pseudo-headers are not mentioned.

5.5.  Extending HTTP/2
https://tools.ietf.org/html/rfc7540#section-5.5

"   HTTP/2 permits extension of the protocol.  Within the limitations
"   described in this section, protocol extensions can be used to provide
"   additional services or alter any aspect of the protocol.  Extensions
"   are effective only within the scope of a single HTTP/2 connection.

and

"   Extensions are permitted to use new frame types (Section 4.1), new
"   settings (Section 6.5.2), or new error codes (Section 7).  Registries
"   are established for managing these extension points: frame types
"   (Section 11.2), settings (Section 11.3), and error codes
"   (Section 11.4).

This makes unclear that extensions are permitted to use new pseudo
header fields or other elements mentioned on HTTP/2 which are not
listed on here.

Of course you can change anything by saying that specification
updates RFC 7540.

/ Kari Hurtta

---

From: Mike Bishop <[email-masked]>
Date: Sat, 11 Nov 2017 21:33:28 +0000

"any aspect of the protocol" seems clear enough to me.  Though perhaps it was an oversight not to have a registry for new pseudo-headers.

-----Original Message-----
From: hurtta@[192.168.0.26] [mailto:hurtta@[192.168.0.26]] On Behalf Of Kari Hurtta
Sent: Sunday, November 12, 2017 5:07 AM
To: HTTP Working Group <[email-masked]>
Cc: Kari Hurtta <[email-masked]>; Patrick McManus <[email-masked]>; Cory Benfield <[email-masked]>
Subject: Extending HTTP/2 | Re: New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt

5.5.  Extending HTTP/2

and

This makes unclear that extensions are permitted to use new pseudo header fields or other elements mentioned on HTTP/2 which are not listed on here.

Of course you can change anything by saying that specification updates RFC 7540.

/ Kari Hurtta

---

From: Patrick McManus <[email-masked]>
Date: Sat, 11 Nov 2017 22:24:51 +0000 (UTC)

I'm with Mike. It also gives the rather more radical example of changing
the layout of the HEADERS frame, which is not a manifestation of the
enumerated mechanisms either and would certainly violate otherwise
normative requirements of non-extended 7540.. the "limitations" it is
referring to is fundamentally the need for opt-in for this kind of change -
not a limitation against the change itself.

On Sun, Nov 12, 2017 at 5:33 AM, Mike Bishop <[email-masked]> wrote:

> "any aspect of the protocol" seems clear enough to me.  Though perhaps it
> was an oversight not to have a registry for new pseudo-headers.
>
> Cc: Kari Hurtta <[email-masked]>; Patrick McManus <
> [email-masked]>; Cory Benfield <[email-masked]>
> Subject: Extending HTTP/2 | Re: New Version Notification for
> draft-mcmanus-httpbis-h2-websockets-00.txt
>
> This makes unclear that extensions are permitted to use new pseudo header
> fields or other elements mentioned on HTTP/2 which are not listed on here.
>

---

From: Patrick McManus <[email-masked]>
Date: Sat, 11 Nov 2017 23:01:16 +0000 (UTC)

On Fri, Nov 10, 2017 at 3:52 PM, Julian Reschke <[email-masked]>
wrote:

>> tries to draw a bright line between extensions that can be ignored safely
>> and those that cannot and need to be negotiated (such as this one). Enjoy
>> the example in there about changing the layout of the HEADERS frame :).
>> This is also why extensions are hop to hop.
>>
>> already very special purpose - so the exception doesn't pollute very far as
>> a practical matter.
>> ...
>>
>
> But still, it leaks. What if a different extension that wants to co-exist
> with this one wants to define a pseudo header field with the same name?
>
>
obviously extensions can collide - that's not a very practical problem when
they are opt-in.

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 12 Nov 2017 08:27:25 +0800

I now do not think that "upgrade" needs to be a pseudo header.

The reason I proposed having :upgrade: pseudo header was due to my
understanding that HTTP/2 prohibited hop-by-hop headers, and that we
are trying to revive the "upgrade" hop-by-hop header of HTTP/1 by
trying to implement Websocket (or a generic upgrade) on HTTP/2. It
seemed to me that defining it as an extraordinary header (i.e. pseudo
header) seemed to make sense.

But reconsidering this, I now believe that what we are trying to
define is an end-to-end upgrade of a stream. In H2WS, we use a
SETTINGS parameter for hop-by-hop negotiation.

So now, it seems to me that defining the header as an ordinary (i.e.
non-pseudo) header is fine.

2017-11-12 6:24 GMT+08:00 Patrick McManus <[email-masked]>:
> I'm with Mike. It also gives the rather more radical example of changing the
> layout of the HEADERS frame, which is not a manifestation of the enumerated
> mechanisms either and would certainly violate otherwise normative
> requirements of non-extended 7540.. the "limitations" it is referring to is
> fundamentally the need for opt-in for this kind of change - not a limitation
> against the change itself.
>
>
>> Cc: Kari Hurtta <[email-masked]>; Patrick McManus
>> <[email-masked]>; Cory Benfield <[email-masked]>

-- 
Kazuho Oku

---

From: Patrick McManus <[email-masked]>
Date: Sun, 12 Nov 2017 04:41:12 +0000 (UTC)

> header) seemed to make sense.
a colon header is a transport specific (i.e. hop to hop) header. In the
context of what I have proposed, that's what I'm looking for - it changes
the dynamics of the transaction into a fully bidirectional channel and
that's transport specific. A non-colon upgrade header could be forwarded
onto a transport that did not allow it.

---

From: Kari Hurtta <[email-masked]>
Date: Sun, 12 Nov 2017 09:44:20 +0200 (EET)

Kazuho Oku <[email-masked]>: (Sun Nov 12 02:27:25 2017)
> understanding that HTTP/2 prohibited hop-by-hop headers, and that we

( on here I aggreed with Patrick McManus <[email-masked]>:
  "a colon header is a transport specific (i.e. hop to hop) header. 
  … it changes the dynamics of the transaction into a fully bidirectional 
  channel and that's transport specific."
  https://lists.w3.org/Archives/Public/ietf-http-wg/2017OctDec/0241.html )

> SETTINGS parameter for hop-by-hop negotiation.

1) forward proxyes (which are configured to browser) still use regular
   CONNECT -method.

   https://github.com/mcmanus/draft-h2ws/blob/master/draft-mcmanus-httpbis-h2-websockets-02.txt

"   This document does not change how WebSockets interacts with HTTP
"   proxies.  If a client wishing to speak WebSockets connects via HTTP/2
"   to a HTTP proxy it should continue to use a traditional (i.e. not
"   with a :protocol pseudo-header) CONNECT to tunnel through that proxy
"   to the WebSocket server via HTTP.

4.1.  Client Requirements
https://tools.ietf.org/html/rfc6455#section-4.1

"   3.  _Proxy Usage_: If the client is configured to use a proxy when
"       using the WebSocket Protocol to connect to host /host/ and port
"       /port/, then the client SHOULD connect to that proxy and ask it
"       to open a TCP connection to the host given by /host/ and the port
"       given by /port/.
"
"          EXAMPLE: For example, if the client uses an HTTP proxy for all
"          traffic, then if it was to try to connect to port 80 on server
"          example.com, it might send the following lines to the proxy
"          server:
"
"              CONNECT example.com:80 HTTP/1.1
"              Host: example.com

2) It is reverse proxies which see Upgrade: on HTTP/1.1 and 

    :method = CONNECT
    :protocol = websocket

  on HTTP/2. These reverse proxies listen IP address which resolves
  from name given on Host -header or :authority pseudo header.

  I often also refer situation where reverse proxy does TLS
  offloading — TLS is terminated on reverse proxy.

  ( Often reverse proxy ↔ backend server connection is 
    not encrypted — sometimes it is re-encrypted — there
    is another TLS connection to backend server. )

/ Kari Hurtta

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 13 Nov 2017 10:20:19 +0100

> Am 12.11.2017 um 05:41 schrieb Patrick McManus <[email-masked]>:
> 
> 
> a colon header is a transport specific (i.e. hop to hop) header. In the context of what I have proposed, that's what I'm looking for - it changes the dynamics of the transaction into a fully bidirectional channel and that's transport specific. A non-colon upgrade header could be forwarded onto a transport that did not allow it.
>  

+1