Subject: Re: [hybi] 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: Sun, 12 Nov 2017 09:44:20 +0200 (EET)

Kazuho Oku <[email-masked]>: (Sun Nov 12 02:27:25 2017)
> 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

( 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 )

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

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