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

From: Patrick McManus <[email-masked]>
Date: Sun, 15 Oct 2017 14:12:02 +0000 (UTC)

FYI - also see https://github.com/mcmanus/draft-h2ws/blob/master/README.md

Comments, expressions of interest, etc are very welcome.

---------- Forwarded message ----------
From: <[email-masked]>
Date: Sun, Oct 15, 2017 at 10:08 AM
Subject: New Version Notification for
draft-mcmanus-httpbis-h2-websockets-00.txt
To: Patrick McManus <[email-masked]>

A new version of I-D, draft-mcmanus-httpbis-h2-websockets-00.txt
has been successfully submitted by Patrick McManus and posted to the
IETF repository.

Name:           draft-mcmanus-httpbis-h2-websockets
Revision:       00
Title:          Bootstrapping WebSockets with HTTP/2
Document date:  2017-10-15
Group:          Individual Submission
Pages:          7
URL:            https://www.ietf.org/internet-drafts/draft-mcmanus-httpbis-
h2-websockets-00.txt
Status:         https://datatracker.ietf.org/doc/draft-mcmanus-httpbis-h2-
websockets/
Htmlized:       https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-
websockets-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-mcmanus-
httpbis-h2-websockets-00

Abstract:
   This document defines a mechanism for running the WebSocket Protocol
   [RFC6455] over a single stream of an HTTP/2 connection.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Cory Benfield <[email-masked]>
Date: Sun, 15 Oct 2017 08:43:02 -0700

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?

Cory

> On 15 Oct 2017, at 07:12, Patrick McManus <[email-masked]> wrote:
> 
> Subject: New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt
> URL:            https://www.ietf.org/internet-drafts/draft-mcmanus-httpbis-h2-websockets-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-mcmanus-httpbis-h2-websockets/
> Htmlized:       https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-websockets-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-mcmanus-httpbis-h2-websockets-00
> 
> 
> Abstract:

---

From: Patrick McManus <[email-masked]>
Date: Sun, 15 Oct 2017 18:39:34 +0000 (UTC)

On Sun, Oct 15, 2017 at 11:43 AM, Cory Benfield <[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?
>
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.

> URL:            https://www.ietf.org/internet-
> drafts/draft-mcmanus-httpbis-h2-websockets-00.txt
> Htmlized:       https://datatracker.ietf.org/
> doc/html/draft-mcmanus-httpbis-h2-websockets-00
>
>
> Abstract:

---

From: Patrick McManus <[email-masked]>
Date: Sun, 15 Oct 2017 16:38:59 -0400

Hey Andy - it sounds like my 2 mails on this thread mght not have been
posted to hybi? I'll try here with @mozilla.com addr. Thanks for the note.

On Sun, Oct 15, 2017 at 3:24 PM, Andy Green <[email-masked]> wrote:

> 2)
> This simply isn't true,

thanks. I'll rephrase

> 4) The draft should spell out it carries ws payload unchanged in h2
> frames.

   Streams that have been successfully established as protocol tunnels
   proceed to establish and utilize the WebSocket Protocol using the
   procedure defined by [RFC6455
<https://tools.ietf.org/html/rfc6455>] treating the stream as if were
the
   connection in that specification.

Obviously there are approaches that could do far more significant things to
the protocol. This is a shim for bootstrapping 6455, otherwise 6455 remains
in tact.

5) Hybi originally did the ws handshake key dance with hashes to ensure
> there were no inadvertant ws handshakes

see 4.

> 6) If you make the ws key dance roundtrip optional, something to keep h1
> clients happy who don't know they're on h2, then you can PUSH_PROMISE a ws
> upgrade on a specific subprotocol unilaterally, eliminating roundtrips.  If
> you are serving html with a

you can only push safe methods. connect is not safe. Again, I agree you
could remove an rtt (or probably 2) with a different approach at a cost of
higher complexity and changes. That's not the target here.

\

> >Section 8.1.2.1, which says endpoints MUST NOT generate new
> >pseudo-header fields?
> >
> That is a good point... won't a new Sec-whatever do?  Being able to use
> whatever it is in PUSH_PROMISE to unilaterally offer an unambiguous
> pre-upgraded ws stream would be very nice.
>

I answered this is a message that probably wasn't posted to hybi
https://lists.w3.org/Archives/Public/ietf-http-wg/2017OctDec/0034.html..
tl;dr; an opt-in extension lets you amend 7540 in ways that would be
protocol violations without the opt-in.

pseudo-headers are meant to control protocol level features and are unique
to that version of the protocol - so this helps ensure that the Sec- header
wasn't introduced by some other non h2 application .

-Patrick

> -Andy
> >> FYI - also see
> >https://github.com/mcmanus/draft-h2ws/blob/master/README.md
> >>
> >> URL:
> >https://www.ietf.org/internet-drafts/draft-mcmanus-
> httpbis-h2-websockets-00.txt
> >> Status:
> >https://datatracker.ietf.org/doc/draft-mcmanus-httpbis-h2-websockets/
> >> Htmlized:
> >https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-websockets-00
> >> Htmlized:
> >https://datatracker.ietf.org/doc/html/draft-mcmanus-
> httpbis-h2-websockets-00
> >>
> >>
> >> Abstract:

---

From: Andy Green <[email-masked]>
Date: Mon, 16 Oct 2017 10:38:56 +0800

On 10/16/2017 04:38 AM, Patrick McManus wrote:
> posted to hybi? I'll try here with @mozilla.com <http://mozilla.com> 
> addr. Thanks for the note.

>     procedure defined by [RFC6455 <https://tools.ietf.org/html/rfc6455>] treating the stream as if were the
> Obviously there are approaches that could do far more significant things 
> to the protocol. This is a shim for bootstrapping 6455, otherwise 6455 
> remains in tact.

Yes... it should probably spell that out for DATA though, something like:

"Once upgraded, the h2 stream is used to transport the ws frames by 
enclosing them in h2 DATA frames.  There is no specific relationship 
between h2 DATA fragment sizes carrying the ws frames and the ws frame 
sizes; the h2 frames may refragment the original ws frames arbitrarily, 
eg to meet mux latency goals across multiple streams.

Although the DATA frames used for encapsulation are not distinguishable 
from DATA frames used for h2 http transport, note unlike DATA frames 
used for http they are not restricted in either direction by 
content-length and they may appear in either direction continuously, 
until END_STREAM appears.".

>     5) Hybi originally did the ws handshake key dance with hashes to
>     ensure there were no inadvertant ws handshakes
> 
> 
> see 4.

Not suggesting to change that...

>     6) If you make the ws key dance roundtrip optional, something to
>     keep h1 clients happy who don't know they're on h2, then you can
>     PUSH_PROMISE a ws upgrade on a specific subprotocol unilaterally,
>     eliminating roundtrips.  If you are serving html with a 
> 
> could remove an rtt (or probably 2) with a different approach at a cost 
> of higher complexity and changes. That's not the target here.

Well, it looks like you don't want to do it.  This thing would be an 
optional optimization it doesn't affect what you have at the moment.

PUSH_PROMISE has some restrictions as defined in RFC7450 8.2, like 
"Promised requests MUST be cacheable" which would need working around. 
It's also slightly different in that ws is bidirectional, normal 
PUSH_PROMISE the server manages delivering the promise or not, and the 
client can accept stuff to cache at any time or RST him.

But with ws PUSH_PROMISE content, there'd be a race between the script 
trying to instantiate the ws connection after the HTML was received so 
it has a context to use the ws link, and the server deciding to try send 
something.  It can be handled by defining the initial tx window to be 0 
for ws PUSH_PROMISE streams and the client must explicitly allow it to send.

Here's what I think it means for RTT... first the default as it is

Client				Server

  - SETTINGS                      - SETTINGS
  - GET /index.html
				 - 200 HEADERS + DATA

  - :method CONNECT
  				 - 200 HEADERS

  - DATA ws handshake
				 - DATA ws handshake final

  - DATA ...			 - DATA...

So after the h2 link is up, he needs 3 x roundtrips to send some ws 
data.  With an optional PUSH_PROMISE that the client feels he can use...

  - SETTINGS                      - SETTINGS
  - GET /index.html
				 - 200 HEADERS + DATA
				 - PUSH_PROMISE ws contains
				   ws handshake final

  - WINDOW_UPDATE (see below)
  - DATA ...
				 - DATA...

It's just one (client -> server) or 1.5 (server -> client) roundtrips 
instead of 3.

Anyway if nobody else wants it, no point worrying about it.

-Andy

>     That is a good point... won't a new Sec-whatever do?  Being able to
>     use whatever it is in PUSH_PROMISE to unilaterally offer an
>     unambiguous pre-upgraded ws stream would be very nice.
> 
> 
> pseudo-headers are meant to control protocol level features and are 
> unique to that version of the protocol - so this helps ensure that the 
> Sec- header wasn't introduced by some other non h2 application .
> 
> -Patrick
> 
> 
>     -Andy
> 
>      >Cory
>      >
>      >> On 15 Oct 2017, at 07:12, Patrick McManus <[email-masked]
>     <mailto:[email-masked]>>
>      >wrote:
>      >>
>      >> FYI - also see
>     <https://github.com/mcmanus/draft-h2ws/blob/master/README.md>
>      >>
>      >> From: <[email-masked] <mailto:[email-masked]>>
>      >> To: Patrick McManus <[email-masked]
>     <mailto:[email-masked]>>
>      >>
>      >>
>      >>
>      >https://www.ietf.org/internet-drafts/draft-mcmanus-httpbis-h2-websockets-00.txt <https://www.ietf.org/internet-drafts/draft-mcmanus-httpbis-h2-websockets-00.txt>
>      >> Status:
>      >https://datatracker.ietf.org/doc/draft-mcmanus-httpbis-h2-websockets/ <https://datatracker.ietf.org/doc/draft-mcmanus-httpbis-h2-websockets/>
>      >> Htmlized:
>     <https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-websockets-00>
>      >> Htmlized:
>      >https://datatracker.ietf.org/doc/html/draft-mcmanus-httpbis-h2-websockets-00 <https://datatracker.ietf.org/doc/html/draft-mcmanus-httpbis-h2-websockets-00>
>      >>
>      >>
>      >> Abstract:
>      >> until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>.
>      >>
>      >> The IETF Secretariat
>      >>
>      >>
> 
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Oct 2017 13:51:52 +1100

On Mon, Oct 16, 2017 at 1:38 PM, Andy Green <[email-masked]> wrote:
> So after the h2 link is up, he needs 3 x roundtrips to send some ws data.

I think that you are exaggerating the cost here.  The ws handshake and
CONNECT can be sent together.  The only real burden that Patrick's
design adds is the need to test that the server is willing to use this
design.

FWIW, if this were me, I would look at trimming the websocket
handshake instead.  Much of the overhead there is what will hurt the
overall latency.  If you took the setting as an indication that this
was an acceptable protocol, you could remove all the Upgrade business
and just start sending ws frames.  But I think that Patrick is right
to start with the minimal thing; I would recommend only doing that
with a new protocol identifier.

---

From: Andy Green <[email-masked]>
Date: Mon, 16 Oct 2017 10:57:53 +0800

> I think that you are exaggerating the cost here.  The ws handshake and

Eh... why do you say that?  It takes less than 3 RTs?

> design adds is the need to test that the server is willing to use this

Maybe it's not clear from the formatting, but I based this from p4 of 
Patrick's draft, here is the original

   [[ From Client ]]                        [[ From Server ]]

                                            SETTINGS
                                            ENABLE_CONNECT_PROTOCOL = 1

   HEADERS + END_HEADERS
   :method = CONNECT
   :protocol = websocket
   :scheme = wss
   :path = /chat
   :authority = server.example.com:443

                                            HEADERS + END_HEADERS
                                            :status = 200

   DATA
   GET /chat HTTP/1.1
   Host: server.example.com
   Upgrade: websocket
   Connection: Upgrade
   Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
   Origin: http://example.com
   Sec-WebSocket-Protocol: chat, superchat
   Sec-WebSocket-Version: 13

                                            DATA
                                            HTTP/1.1 101 Plead The Fifth
                                            Upgrade: websocket
                                            Connection: Upgrade
                                            Sec-WebSocket-Accept:
                                             s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
                                            Sec-WebSocket-Protocol: chat

   DATA
   WebSocket Data

                                            DATA + END_STREAM
                                            WebSocket Data

   DATA + END_STREAM
   WebSocket Data

That is 3 RTT, right?

> handshake instead.  Much of the overhead there is what will hurt the

He needs to support dumb http/1 ws clients that find themselves hitching 
a ride on a h2 bundle.  So they need all the headers they expect.

That's why I don't suggest any changes there, but as an optimization for 
h2-aware ws client skip all that legacy junk and just provide the end 
result in the PUSH_PROMISE.

> with a new protocol identifier.

That is what I suggested on both counts :-)

-Andy

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Oct 2017 14:01:46 +1100

> That is 3 RTT, right?

I'm basing this off how I understand h2 to work, and the example in
the draft shows an unnecessary extra RTT; that's all.

---

From: Andy Green <[email-masked]>
Date: Mon, 16 Oct 2017 11:08:29 +0800

> the draft shows an unnecessary extra RTT; that's all.

Patrick himself says "...Again, I agree you could remove an rtt (or 
probably 2)..."

I think you misunderstood something... as it is he has to wait for the 
SETTINGs to tell him it's possible, wait for the CONNECT and response 
and wait for the ws handshake to go through before he can send 
something.  It's 3 x RTT AFAICS and nothing is "exaggerat[ed]".

That's alright if it's the default situation for HTTP/1 ws guys... but 
there should be a way like PUSH_PROMISE to dispense will all that junk 
for what will be increasingly common native-h2 ws client.

-Andy

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Oct 2017 14:57:26 +1100

On Mon, Oct 16, 2017 at 2:08 PM, Andy Green <[email-masked]> wrote:
> SETTINGs to tell him it's possible, wait for the CONNECT and response and
> wait for the ws handshake to go through before he can send something.

No, I'm just saying that if you proceed like the CONNECT will work,
then you can save an RTT over that.  Given that you have a clear
indication that the server accepts WS, then you don't need to worry
about this.

Keep in mind that you don't have to wait a round trip for the server
SETTINGS frame in TLS 1.3.  That means that you aren't saving much
with any of these extra steps.

---

From: Andy Green <[email-masked]>
Date: Mon, 16 Oct 2017 12:06:09 +0800

> with any of these extra steps.

The sequence I gave for counting the RTT includes fetching the html with 
the script that wants to make the connection; until the client gets that 
he cannot start with the ws connection.  This is the typical situation 
for ws connections and in the case the same h2 connection is providing 
everything, it will be the normal case there too.

Client                Server

  - SETTINGS                      - SETTINGS
  - GET /index.html
                  - 200 HEADERS + DATA

  - :method CONNECT
                   - 200 HEADERS

  - DATA ws handshake

  - DATA ...             - DATA...

  - SETTINGS                      - SETTINGS
  - GET /index.html
                  - 200 HEADERS + DATA

What you are saying will save time I already assume is "for free" since 
it happens during the time the HTML is fetched.

If I am missing the point, could you edit the above copied unchanged 
from my earlier mail to show me the point I am missing?

-Andy

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Oct 2017 15:15:31 +1100

On Mon, Oct 16, 2017 at 3:06 PM, Andy Green <[email-masked]> wrote:
> What you are saying will save time I already assume is "for free" since it
> happens during the time the HTML is fetched.

Assuming that you need to some HTML, that will take a round trip, but
that is concurrent with learning that the server supports websockets.
After that, you should be able to CONNECT and send any frames at the
same time:

C: SETTINGS
C: GET /index.html
S: SETTINGS  <-- I support :protocol
S: 200 + DATA
C: CONNECT + ws hs + DATA <-- client's first WS frames
S: 200 + ws hs + DATA <-- server's first WS frames

Still only two round trips.

Were you concerned that the client needs to learn that the server
supports websockets and not just :protocol?

---

From: Andy Green <[email-masked]>
Date: Mon, 16 Oct 2017 12:44:07 +0800

> C: CONNECT + ws hs + DATA <-- client's first WS frames

Well, you can't pipeline all those.  The way ws works the client 
proposes one or more protocols and extensions.  The server looks at what 
was sent and picks one protocol and zero or more extensions...

> S: 200 + ws hs + DATA <-- server's first WS frames

...only after receiving the server's decision in the final ws hs 
headers, can the client send any ws data, because until then he doesn't 
know the disposition of the ws subprotocol or extensions for the stream.

You can probably pipeline the CONNECT + ws handshake though, Patrick 
shows them sequentially and I didn't think about it myself.

  - SETTINGS                      - SETTINGS
  - GET /index.html
                  - 200 HEADERS + DATA

  - :method CONNECT
  - DATA ws handshake
                   - 200 HEADERS

  - DATA ...             - DATA...

With the part of the pipelining that is legal for ws, two round trips 
before the client can start to send data and 1.5 before the server can 
send data... if it's true then you're right it's not so bad.

> supports websockets and not just :protocol?

No I just followed Patrick's sequencing; he shows them serialized.  But 
you're right at least the CONNECT + ws handshake can probably be pipelined.

That's also going to be a variation from normal h2 HEADERS flow if I 
understood it, on one stream there will be END_HEADERs coming twice (for 
the CONNECT and the ws handshake separately)

Anyway you are right, it makes any difference with PUSH_PROMISE probably 
not worth the effort.

-Andy

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Oct 2017 16:21:45 +1100

On Mon, Oct 16, 2017 at 3:44 PM, Andy Green <[email-masked]> wrote:
> Well, you can't pipeline all those.  The way ws works the client proposes
> one or more protocols and extensions.  The server looks at what was sent and
> picks one protocol and zero or more extensions...

True, I was sort of assuming that you only had one option.  If you
have two, you could create a CONNECT for both and send the data twice.
It's a multiplexed protocol after all.  You would have to avoid
non-idemponent actions, of course.

---

From: Jesse Wilson <[email-masked]>
Date: Mon, 16 Oct 2017 08:34:32 +0000

I think this proposal is a nice shortcut to getting the benefits of
websockets on HTTP/2 without redesigning much. It’s something we could
probably add to OkHttp and MockWebServer in just a few days.

There’s a policy question on what clients should do when a websocket is the
first request to a target host. We can build an HTTP/2 connection and then
hope to layer websockets on top, or build a bare websockets connection
directly and forgo HTTP/2 multiplexing. Browsers might choose to persist
settings to inform this decision. Or it would be handy to hint this in the
ALPN protocols, though that would require the TLS layer to be aware of this
setting!

It’s worth explaining what should happen if a naughty client doesn’t
attempt a websocket upgrade within the DATA frames of a stream established
for that purpose. In particular, a naïve webserver might honor any HTTP/1
request here; that seems like a potential attack vector. Suppose I send
this:

  GET /admin HTTP/1.1
  host: localhost

Can I can trick a server into treating my request as originating from
localhost? The HTTP/2 layer will have already routed the authority for this
request but an attacker could contradict that!

Nice to see a websockets and HTTP/2 proposal. Thanks!

– Jesse

---

From: Patrick McManus <[email-masked]>
Date: Mon, 16 Oct 2017 08:15:54 -0400

On Mon, Oct 16, 2017 at 12:44 AM, Andy Green <[email-masked]> wrote:

>
> You can probably pipeline the CONNECT + ws handshake though, Patrick shows
> them sequentially and I didn't think about it myself.
>
>
right. The example is just for clarity and cannot show all expressions of
h2 flows.

CONNECT + DATA before the response headers is pretty much the h2 analog of
TCP Fast Open. The devil is in the details.. That's a general CONNECT +
DATA issue not limited to the protocol upgrade described here so I don't
think its worth discussion in a websockets rfc.

I think the path to success here hinges on a very tight scoping of work and
therefore optimizing handshake latency is a non-goal of this effort.

> before the client can start to send data and 1.5 before the server can send
> data... if it's true then you're right it's not so bad.
>

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 16 Oct 2017 15:33:00 +0000

Hi Patrick,

Interesting, thanks.

Some comments:

1) In section 3:

A sender MUST NOT send a ENABLE_CONNECT_PROTOCOL parameter with the
value of 0 after previously sending a value of 1.

What should the client do in such a situation? It seems overzealous to call this a protocol error, maybe we could

just say that since the initial/default is 0, a change to 1 is sticky and therefore the client MUST ignore any

ENABLE_CONNECT_PROTOCOL with a value of 0. A different way to look at this is that as the document stands,

sending ENABLE_CONNECT_PROTOCOL with a value of 0 is meaningless.

1) In section 7:

The use of a pseudo-header is something that is connection
specific and HTTP/2 does not ever allow to be created outside of
the protocol stack.

I think I understand the intent of this paragraph but I'm not sure its qualified by anything. Is there something that RFC 7540 says on the matter, or is this based on your observation of H2 implementation stacks?

2) In section 8 the error code 0x8 is reserved, however the HTTP/2 Settings registry indicates 0x7 is free. Is this skip over intended?

Cheers
Lucas

________________________________
From: Patrick McManus [[email-masked]]
Sent: 15 October 2017 15:12
To: HTTP Working Group; hybi
Subject: Fwd: New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Sun, Oct 15, 2017 at 10:08 AM
Subject: New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt
To: Patrick McManus <[email-masked]<mailto:[email-masked]>>

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

---

From: Mike Bishop <[email-masked]>
Date: Mon, 16 Oct 2017 17:13:19 +0000

Generalizing CONNECT to allow you to tunnel protocols other than TCP – or rather, to explicitly state what protocol the other side should be expecting the TCP connection to speak – is a neat approach.  So first off, kudos!

If you say you’re upgrading to WebSockets, then I’d expect it to actually upgrade straight to WebSockets, not an HTTP/1.1 request which is expected to then upgrade to WebSockets.  I understand that would entail putting all the WebSocket negotiation headers on the CONNECT itself, etc. and I’m sympathetic to the argument that it is a larger change that may produce a roadbump.  But you’re making a commitment at the HTTP/2 layer that actually means nothing (“wss” scheme, “websocket” :protocol).

Given that you’re doing the full Upgrade-to-WebSockets dance inside the tunneled connection, why don’t you just say that you’re CONNECTing to an HTTP/1.1 tunnel?  That’s then treated as HTTP/1.1 over TCP, which is fully allowed to do Upgrade itself.  If you’re sure that’s the path you want, then simply say in the HTTP/2 layer that you’re doing HTTP/1.1 inside the stream.  Incidentally, that might be a nice alternative for dealing with HTTP_1_1_REQUIRED responses, too!

From: Patrick McManus [mailto:[email-masked]]
Sent: Monday, October 16, 2017 5:16 AM
To: Andy Green <[email-masked]>
Cc: Martin Thomson <[email-masked]>; Patrick McManus <[email-masked]>; hybi <[email-masked]>; Cory Benfield <[email-masked]>; Patrick McManus <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt

On Mon, Oct 16, 2017 at 12:44 AM, Andy Green <[email-masked]<mailto:[email-masked]>> wrote:

You can probably pipeline the CONNECT + ws handshake though, Patrick shows them sequentially and I didn't think about it myself.

right. The example is just for clarity and cannot show all expressions of h2 flows.

CONNECT + DATA before the response headers is pretty much the h2 analog of TCP Fast Open. The devil is in the details.. That's a general CONNECT + DATA issue not limited to the protocol upgrade described here so I don't think its worth discussion in a websockets rfc.

I think the path to success here hinges on a very tight scoping of work and therefore optimizing handshake latency is a non-goal of this effort.

 - SETTINGS                      - SETTINGS
 - GET /index.html
                 - 200 HEADERS + DATA

 - :method CONNECT
 - DATA ws handshake
                  - 200 HEADERS

 - DATA ...             - DATA...

With the part of the pipelining that is legal for ws, two round trips before the client can start to send data and 1.5 before the server can send data... if it's true then you're right it's not so bad.
Were you concerned that the client needs to learn that the server
supports websockets and not just :protocol?

No I just followed Patrick's sequencing; he shows them serialized.  But you're right at least the CONNECT + ws handshake can probably be pipelined.

That's also going to be a variation from normal h2 HEADERS flow if I understood it, on one stream there will be END_HEADERs coming twice (for the CONNECT and the ws handshake separately)

Anyway you are right, it makes any difference with PUSH_PROMISE probably not worth the effort.

-Andy

---

From: Patrick McManus <[email-masked]>
Date: Mon, 16 Oct 2017 17:31:45 -0400

On Mon, Oct 16, 2017 at 1:13 PM, Mike Bishop <[email-masked]>
wrote:

> Generalizing CONNECT to allow you to tunnel protocols other than TCP – or
> rather, to explicitly state what protocol the other side should be
> expecting the TCP connection to speak – is a neat approach.  So first off,
> kudos!
>
>
>
> If you say you’re upgrading to WebSockets, then I’d expect it to actually
> upgrade straight to WebSockets, not an HTTP/1.1 request which is expected
> to then upgrade to WebSockets.  I understand that would entail putting all
> the WebSocket negotiation headers on the CONNECT itself, etc. and I’m
> sympathetic to the argument that it is a larger change that may produce a
> roadbump.  But you’re making a commitment at the HTTP/2 layer that actually
> means nothing (“wss” scheme, “websocket” :protocol).
>
>
I hear what you're saying.. but I think you're going a touch too far.
websocket means 6455 which has all that h1 stuff as part of its
configuration.. I think it would be totally fair to say such a server could
have a more constrained parser that failed any non-ws compliant handshake
even if it were valid h1. Mostly I think it becomes an insanely ugly what
to do websocket parameter exchange.

I think of origin info (scheme and authority) more as keys to route the
CONNECT request.. it's :protocol that defines what to do in the tunnel. I
admit I did consider calling it :alpn (which has a similar kind of
property.. its a route of sorts but it doesn't bear the SETTINGS or magic
of h2)

You have kind of let the cat out of the bag at just doing an h1 connect.
That's actually possible with the draft (or at least envisioned) as I
defined :protocol separate from the websocket specific stuff... but I kinda
hope to never speak of it again :)

This is a tough one - its definitely going for simplicity as its main
goal.. that means ignoring many places that can be improved. That's a
choice based on
 a] the history of other efforts seem to suggest there is no stomach for
complexity/risk here
 b] we hear about this problem enough that I think its worth seeing if this
can be m ade a consensus mvp
 c] my belief that websockets is a transitional technology - it will be
around for years but some kind of native http will supplant it.

ymmv (more than usual on this one!)

-P

>
>
> Given that you’re doing the full Upgrade-to-WebSockets dance inside the
> tunneled connection, why don’t you just say that you’re CONNECTing to an
> HTTP/1.1 tunnel?  That’s then treated as HTTP/1.1 over TCP, which is fully
> allowed to do Upgrade itself.  If you’re sure that’s the path you want,
> then simply say in the HTTP/2 layer that you’re doing HTTP/1.1 inside the
> stream.  Incidentally, that might be a nice alternative for dealing with
> HTTP_1_1_REQUIRED responses, too!
>
>
>
> *From:* Patrick McManus [mailto:[email-masked]]
> *Sent:* Monday, October 16, 2017 5:16 AM
> *To:* Andy Green <[email-masked]>
> *Cc:* Martin Thomson <[email-masked]>; Patrick McManus <
> [email-masked]>; hybi <[email-masked]>; Cory Benfield <
> [email-masked]>; Patrick McManus <[email-masked]>; HTTP Working
> Group <[email-masked]>
> *Subject:* Re: [hybi] New Version Notification for
> I think the path to success here hinges on a very tight scoping of work
> and therefore optimizing handshake latency is a non-goal of this effort.
>
>
>
>
>

---

From: Andy Green <[email-masked]>
Date: Sun, 15 Oct 2017 19:25:33 +0000

On October 15, 2017 11:43:02 PM GMT+08:00, Cory Benfield <[email-masked]> wrote:

Cory, thanks for cc-ing hybi.  I reply with comments about the draft first.

1) it's great that after a few years someone with influence woke up to the fact ws was frozen out of h2 and that, as was publicly foreseen by several people, it would be a PITA to leave it at "let them eat h1".

2) 'From the draft: 'A server offering both HTTP/1.1 and WebSocket services can do so from the same instance and same port although they require separate TCP connections. Moving a server to HTTP/2 and WebSocket services requires a separate port and protocol stack for the sole purpose of bootstrapping WebSockets. This is a significant administrative burden and may not even be possible in the case of large amounts of deployed markup pointing at the old single name and port. ''

This simply isn't true, for example libwebsockets supports h1, h2 and wss all on :443 simultaneously; https://libwebsockets.org itself runs on that today.  Nothing stops it except decisions made by the server authors.  "Some popular implementations are not architechted in a way the same listen port can accept sockets destined for h1, h2, and ws" or similar would be more correct.

3) The general approach in the draft is okay.  It just adds ws to h2 which is what was always needed. The general occurance of DATA in each direction differs from that implied by http h2 usage, it's not a problem but maybe should be noted.

4) The draft should spell out it carries ws payload unchanged in h2 frames.  In particular ws has this xor "masking" stuff that is just not needed for end-end h2 ws connections.  It's a shame this scheme leaves eliminating the bloat on the table but better (bloatwise) plans have gone around in circles for years, this draft marks a browser implementor actually wanting to implement something related to h2 ws for the first time I heard of...

5) Hybi originally did the ws handshake key dance with hashes to ensure there were no inadvertant ws handshakes where one side did not really speak it.  It is not required on h2, since if it has the SETTINGS enabled, it asserts it speaks it, although I get it a client for a stream may not know it went over h2, only know h1 and require the dance.  So the old dance should be optional I think.

6) If you make the ws key dance roundtrip optional, something to keep h1 clients happy who don't know they're on h2, then you can PUSH_PROMISE a ws upgrade on a specific subprotocol unilaterally, eliminating roundtrips.  If you are serving html with a script that wants to make the ws connection back, it's a very good bet the client would take up the PUSH_PROMISE with very nice latency improvement.

> are no negotiated extensions in use?

That is a good point... won't a new Sec-whatever do?  Being able to use whatever it is in PUSH_PROMISE to unilaterally offer an unambiguous pre-upgraded ws stream would be very nice.

-Andy

> https://www.ietf.org/internet-drafts/draft-mcmanus-httpbis-h2-websockets-00.txt
>> Status:        
> https://datatracker.ietf.org/doc/html/draft-mcmanus-httpbis-h2-websockets-00
>> 
>> 
>> Abstract:

---

From: Stefan Eissing <[email-masked]>
Date: Tue, 17 Oct 2017 10:58:59 +0200

> Am 16.10.2017 um 23:31 schrieb Patrick McManus <[email-masked]>:
> 
> On Mon, Oct 16, 2017 at 1:13 PM, Mike Bishop <[email-masked]> wrote:
[...]
> 
> I hear what you're saying.. but I think you're going a touch too far. websocket means 6455 which has all that h1 stuff as part of its configuration.. I think it would be totally fair to say such a server could have a more constrained parser that failed any non-ws compliant handshake even if it were valid h1. Mostly I think it becomes an insanely ugly what to do websocket parameter exchange.
> 
> I think of origin info (scheme and authority) more as keys to route the CONNECT request.. it's :protocol that defines what to do in the tunnel. I admit I did consider calling it :alpn (which has a similar kind of property.. its a route of sorts but it doesn't bear the SETTINGS or magic of h2)

Me stupid. Me asking, why not :upgrade?

ht;dr (have time, do read)

As proposed, the CONNNECT seems to say: let's talk HTTP/1.1 on this stream from now on, afaict.

From a server implementation pov that opens a larger can of worms. It would mean warming up the HTTP/1.1 engine for the DATA on this stream. That needs some extra care so that it does only safe things inside a h2 stream. On first glance, it seems to be easier and safer to do the stream :upgrade inside the h2 protocol handling itself.

Just my initial gut reaction...

-Stefan

> You have kind of let the cat out of the bag at just doing an h1 connect. That's actually possible with the draft (or at least envisioned) as I defined :protocol separate from the websocket specific stuff... but I kinda hope to never speak of it again :)
> 
> This is a tough one - its definitely going for simplicity as its main goal.. that means ignoring many places that can be improved. That's a choice based on
>  a] the history of other efforts seem to suggest there is no stomach for complexity/risk here
>  b] we hear about this problem enough that I think its worth seeing if this can be m ade a consensus mvp
>  c] my belief that websockets is a transitional technology - it will be around for years but some kind of native http will supplant it.
>

---

From: Patrick McManus <[email-masked]>
Date: Tue, 17 Oct 2017 10:34:16 -0400

Clearly substituting the h1 exchange out in favor of a new websockets
specific exchange that contained sub-protocol and version tokens would look
better on paper... I actually thought diverging from 6455 would make people
LESS likely to implement. Maybe I'm wrong.

So let's poll - please speak up if you have a ws impl (either client or
server):

If the spec added a new websockets specific parameter negotiation and
removed the H1 syntax it would make me
 a] MORE likely to implement
 b] LESS likely to implement
 c] wouldn't change my behavior but I like it more
 d] wouldn't change my behavior but it would be more painful (or like it
less)
 e] really don't care at all.

On Tue, Oct 17, 2017 at 4:58 AM, Stefan Eissing <
[email-masked]> wrote:

> From a server implementation pov that opens a larger can of worms. It
> would mean warming up the HTTP/1.1 engine for the DATA on this stream. That
> needs some extra care so that it does only safe things inside a h2 stream.
> On first glance, it seems to be easier and safer to do the stream :upgrade
> inside the h2 protocol handling itself.
>
> > Cc: Martin Thomson <[email-masked]>; Patrick McManus <
> > Subject: Re: [hybi] New Version Notification for
> > CONNECT + DATA before the response headers is pretty much the h2 analog
> of TCP Fast Open. The devil is in the details.. That's a general CONNECT +

---

From: Patrick McManus <[email-masked]>
Date: Tue, 17 Oct 2017 10:38:06 -0400

> Me stupid. Me asking, why not :upgrade?
because its not upgrading anything to a higher version. I'm sure 6455 would
have used a different name except they were reusing existing h1
infrastructure.

---

From: Stefan Eissing <[email-masked]>
Date: Tue, 17 Oct 2017 16:40:32 +0200

> Am 17.10.2017 um 16:38 schrieb Patrick McManus <[email-masked]>:
> 
> On Tue, Oct 17, 2017 at 4:58 AM, Stefan Eissing <[email-masked]> wrote:
> 
> because its not upgrading anything to a higher version. I'm sure 6455 would have used a different name except they were reusing existing h1 infrastructure.

rfc7230, ch. 6.7

"The "Upgrade" header field is intended to provide a simple mechanism
   for transitioning from HTTP/1.1 to some other protocol on the same
   connection."

Nothing about version here. I do not mind another header name, but if it does the same thing...

Cheers,

Stefan

---

From: Loïc Hoguin <[email-masked]>
Date: Tue, 17 Oct 2017 15:45:47 +0100

I maintain both a client and server that support Websocket. My opinion:

I would implement either way, but I currently do not have an 
implementation for "HTTP/1.1 over h2 DATA frames" so I would need to 
write new code regardless. It's probably worth pointing out that new 
implementers only interested in h2 and Websocket could skip the whole 
HTTP/1.1 text parsing and all its pitfalls entirely.

I would also be very happy to drop the masking on the Websocket frames 
when using Websocket with h2.

On 10/17/2017 03:34 PM, Patrick McManus wrote:
> specific exchange that contained sub-protocol and version tokens would 
> look better on paper... I actually thought diverging from 6455 would 
> make people LESS likely to implement. Maybe I'm wrong.
> 
>   d] wouldn't change my behavior but it would be more painful (or like 
> it less)
> On Tue, Oct 17, 2017 at 4:58 AM, Stefan Eissing 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
>     > Am 16.10.2017 um 23:31 schrieb Patrick McManus <[email-masked] <mailto:[email-masked]>>:
>     >
>     > On Mon, Oct 16, 2017 at 1:13 PM, Mike Bishop <[email-masked] <mailto:[email-masked]>>
>     wrote:
>     [...]
>     >
>      >From a server implementation pov that opens a larger can of worms.
>     It would mean warming up the HTTP/1.1 engine for the DATA on this
>     stream. That needs some extra care so that it does only safe things
>     inside a h2 stream. On first glance, it seems to be easier and safer
>     to do the stream :upgrade inside the h2 protocol handling itself.
> 
>      > You have kind of let the cat out of the bag at just doing an h1
>     connect. That's actually possible with the draft (or at least
>     envisioned) as I defined :protocol separate from the websocket
>     specific stuff... but I kinda hope to never speak of it again :)
>      >
>      > This is a tough one - its definitely going for simplicity as its
>     main goal.. that means ignoring many places that can be improved.
>     That's a choice based on
>      >  b] we hear about this problem enough that I think its worth
>     seeing if this can be m ade a consensus mvp
>      >  c] my belief that websockets is a transitional technology - it
>     will be around for years but some kind of native http will supplant it.
>      >
>      > Given that you’re doing the full Upgrade-to-WebSockets dance
>     inside the tunneled connection, why don’t you just say that you’re
>     CONNECTing to an HTTP/1.1 tunnel?  That’s then treated as HTTP/1.1
>     over TCP, which is fully allowed to do Upgrade itself.  If you’re
>     sure that’s the path you want, then simply say in the HTTP/2 layer
>     that you’re doing HTTP/1.1 inside the stream.  Incidentally, that
>     might be a nice alternative for dealing with HTTP_1_1_REQUIRED
>     responses, too!
>      >
>      >
>      >
>      > From: Patrick McManus [mailto:[email-masked]
>     <mailto:[email-masked]>]
>      > To: Andy Green <[email-masked] <mailto:[email-masked]>>
>      > Cc: Martin Thomson <[email-masked]
>     <mailto:[email-masked]>>; Patrick McManus
>     <[email-masked] <mailto:[email-masked]>>; hybi
>     <[email-masked] <mailto:[email-masked]>>; Cory Benfield
>     <[email-masked] <mailto:[email-masked]>>; Patrick McManus
>     <[email-masked] <mailto:[email-masked]>>; HTTP Working
>     Group <[email-masked] <mailto:[email-masked]>>
>      > You can probably pipeline the CONNECT + ws handshake though,
>     Patrick shows them sequentially and I didn't think about it myself.
>      >
>      >
>      >
>      > CONNECT + DATA before the response headers is pretty much the h2
>     analog of TCP Fast Open. The devil is in the details.. That's a
>     general CONNECT + DATA issue not limited to the protocol upgrade
>     described here so I don't think its worth discussion in a websockets
>     rfc.
>      >
>      >
>      >
>      > I think the path to success here hinges on a very tight scoping
>     of work and therefore optimizing handshake latency is a non-goal of
>     this effort.
>      >
>      >
>      >
>      >
>      >
>      > With the part of the pipelining that is legal for ws, two round
>     trips before the client can start to send data and 1.5 before the
>     server can send data... if it's true then you're right it's not so bad.
>      >
>      > No I just followed Patrick's sequencing; he shows them
>     serialized.  But you're right at least the CONNECT + ws handshake
>     can probably be pipelined.
>      >
>      > That's also going to be a variation from normal h2 HEADERS flow
>     if I understood it, on one stream there will be END_HEADERs coming
>     twice (for the CONNECT and the ws handshake separately)
>      >
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
> 

-- 
Loïc Hoguin
https://ninenines.eu

---

From: Patrick McManus <[email-masked]>
Date: Tue, 17 Oct 2017 10:48:15 -0400

nothing about versions other than the name Upgrade :)

On Tue, Oct 17, 2017 at 10:40 AM, Stefan Eissing <
[email-masked]> wrote:

> > because its not upgrading anything to a higher version. I'm sure 6455
> would have used a different name except they were reusing existing h1
> infrastructure.
>
> rfc7230, ch. 6.7
>

---

From: Stefan Eissing <[email-masked]>
Date: Tue, 17 Oct 2017 16:52:39 +0200

Thanks for the poll!

> Am 17.10.2017 um 16:34 schrieb Patrick McManus <[email-masked]>:
> 
> Clearly substituting the h1 exchange out in favor of a new websockets specific exchange that contained sub-protocol and version tokens would look better on paper... I actually thought diverging from 6455 would make people LESS likely to implement. Maybe I'm wrong.
> 
> So let's poll - please speak up if you have a ws impl (either client or server):
> 
> If the spec added a new websockets specific parameter negotiation and removed the H1 syntax it would make me
>  d] wouldn't change my behavior but it would be more painful (or like it less)

c)

However, it is not really clear to me why we need another parameter negotiation, 
besides defining what rfc6455, ch. 4.2.1 means by "Upgrade" and "Connection" header
requirements on a h2 stream.

You most likely have more ws experience than myself, so please understand this as a
real question for me and not some rhetoric hand-waving.

To explain my pov: the h2 code sits on the connection/stream, will detect the
to-be-defined equivalent of a "Upgrade: websocket" request header and feed the server-internal,
proprietary websocket implementation all the information it desires. h1/h2 protocol serialization
is basically over at this point.

That is how I look at it. This might be totally different for other peoples implementation, of course.

---

From: Stefan Eissing <[email-masked]>
Date: Tue, 17 Oct 2017 16:54:56 +0200

Ah! Let's agree on newer, better, faster...

In that context, I understand your objection. ^^

> Am 17.10.2017 um 16:48 schrieb Patrick McManus <[email-masked]>:
> 
> On Tue, Oct 17, 2017 at 10:40 AM, Stefan Eissing <[email-masked]> wrote:
> 
>

---

From: Patrick McManus <[email-masked]>
Date: Tue, 17 Oct 2017 11:00:09 -0400

the concept is that CONNECT establishes a HTTP tunnel to a websockets
server.. any websocket stuff happens in that tunnel, any HTTP stuff happens
out at the CONNECT side (so that might be path, authority, cookies for
CONNECT, and version subprotocol extensions and selected subprotocol in the
tunnel..). That's the same flow as the current text, its just a simpler
parser that doesn't drag h1 into things. Smooshing all the options onto the
CONNECT (as they were with the 6455 GET) doesn't really have any perf
benefit assuming you pipeline the DATA frames before the response HEADERS.
(and I'll update the example to show that)

On Tue, Oct 17, 2017 at 10:52 AM, Stefan Eissing <
[email-masked]> wrote:

> > > I think of origin info (scheme and authority) more as keys to route
> the CONNECT request.. it's :protocol that defines what to do in the tunnel.
> I admit I did consider calling it :alpn (which has a similar kind of
> connect. That's actually possible with the draft (or at least envisioned)
> as I defined :protocol separate from the websocket specific stuff... but I
> kinda hope to never speak of it again :)
> > >
> > >  c] my belief that websockets is a transitional technology - it will
> be around for years but some kind of native http will supplant it.
> > >
> > > Given that you’re doing the full Upgrade-to-WebSockets dance inside
> the tunneled connection, why don’t you just say that you’re CONNECTing to
> an HTTP/1.1 tunnel?  That’s then treated as HTTP/1.1 over TCP, which is
> fully allowed to do Upgrade itself.  If you’re sure that’s the path you
> want, then simply say in the HTTP/2 layer that you’re doing HTTP/1.1 inside
> the stream.  Incidentally, that might be a nice alternative for dealing
> with HTTP_1_1_REQUIRED responses, too!
> > >
> > >
> > >
> analog of TCP Fast Open. The devil is in the details.. That's a general
> CONNECT + DATA issue not limited to the protocol upgrade described here so
> I don't think its worth discussion in a websockets rfc.
> > >
> > >
> > >
> > > I think the path to success here hinges on a very tight scoping of
> work and therefore optimizing handshake latency is a non-goal of this
> effort.
> > >
> > >
> > >
> > >
> > >
> > > No I just followed Patrick's sequencing; he shows them serialized.
> But you're right at least the CONNECT + ws handshake can probably be
> pipelined.
> > >

---

From: Mike Bishop <[email-masked]>
Date: Tue, 17 Oct 2017 16:33:45 +0000

This is somewhat conjecture, since I haven’t gone over it with our dev team, but I think it plays out to (c).  We’ve had enough people ask for WebSocket support, it will eventually happen if there’s an interoperable way to do it.  IIRC, Upgrade is pluggable. When a protocol upgrades to websocket, we check if there’s a handler for that protocol.  If so, we return 101 and give control of the TCP connection to that handler; the HTTP layer becomes passthrough.

If we have to support pulling in HTTP/1.1 parsing to that stream simply to do an Upgrade, that’s an additional scenario we have to support in-line first, and an extra layer to go passthrough in the hopefully-common case.  I’d rather be able to hand the stream directly to the WebSocket library (owned by a different team) and be done, even if it means there’s an H2-specific Upgrade path.  (Which, it turns out, there is in this draft already.)

We could still decide to support H2-“upgrade”-to-H1 in the future, but it would be because that’s a feature we found we needed for some reason, not because it was an annoying stepping-stone to something we actually wanted.  (In fact, our most common reason to issue HTTP_1_1_REQUIRED is client certificates, which this won’t help.)

From: Patrick McManus [mailto:[email-masked]]
Sent: Tuesday, October 17, 2017 7:34 AM
To: Stefan Eissing <[email-masked]>
Cc: Patrick McManus <[email-masked]>; Mike Bishop <[email-masked]>; Andy Green <[email-masked]>; Martin Thomson <[email-masked]>; hybi <[email-masked]>; Cory Benfield <[email-masked]>; McManus Patrick <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt

On Tue, Oct 17, 2017 at 4:58 AM, Stefan Eissing <[email-masked]<mailto:[email-masked]>> wrote:

> Am 16.10.2017 um 23:31 schrieb Patrick McManus <[email-masked]<mailto:[email-masked]>>:
>
> On Mon, Oct 16, 2017 at 1:13 PM, Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:
[...]

-Stefan

> From: Patrick McManus [mailto:[email-masked]<mailto:[email-masked]>]
> To: Andy Green <[email-masked]<mailto:[email-masked]>>
> Cc: Martin Thomson <[email-masked]<mailto:[email-masked]>>; Patrick McManus <[email-masked]<mailto:[email-masked]>>; hybi <[email-masked]<mailto:[email-masked]>>; Cory Benfield <[email-masked]<mailto:[email-masked]>>; Patrick McManus <[email-masked]<mailto:[email-masked]>>; HTTP Working Group <[email-masked]<mailto:[email-masked]>>

---

From: Andy Green <[email-masked]>
Date: Wed, 18 Oct 2017 02:19:00 +0800

On October 17, 2017 10:34:16 PM GMT+08:00, Patrick McManus <[email-masked]> wrote:
>look

c) ... as discussed before only three persistant things come from the ws dance, agreement on both sides the stream is in an upgraded state, and the server telling which protocol and any extensions + extension options apply.

For the case where the peer is actually h1 ws hitching a ride on h2, the extra RFC6455-only h1 header bits like Sec key hashes can be synthesized at the boundary where the h1 stuff interfaces to the h2 stream, since they don't feature in the state after upgrade establishment and an h2 server doesn't need to see them at all.

For the case the peer is natively h2 - surely it will become the common case when this arrives in today's h2-preferring web browsers - doing a simpler upgrade in native h2 is easier to implement, just don't do any of the old Sec-key stuff at all.

-Andy

>> As proposed, the CONNNECT seems to say: let's talk HTTP/1.1 on this
>stream
>> from now on, afaict.
>>
>connect.
>main
>> >  b] we hear about this problem enough that I think its worth seeing
>if
>> this can be m ade a consensus mvp
>will be
>Patrick
>> > right. The example is just for clarity and cannot show all
>expressions
>> of h2 flows.
>> >
>> >
>> >
>analog
>work
>trips
>But

---

From: Mike Bishop <[email-masked]>
Date: Wed, 18 Oct 2017 17:59:54 +0000

Having discussed with our dev lead, I think there’s one other barrier here:  State machine.  WebSocket requests that support Upgrade have to go to the resource to decide whether to accept them, and having two “encapsulated” requests is challenging.  Likewise, the client sends two requests, which contorts the exposed state machine on that side.  We could lie and use the states that exist for connecting via a proxy, but if the client isn’t expecting to use a proxy that’s equally problematic.

I think we’re amenable to defining a way to define upgrade-of-stream, but the double-upgrade model is challenging.

Also, he pointed out that legacy WebSockets had the useful property that an unsupporting server would simply handle the vanilla GET, rather than failing entirely.  The server setting partially mitigates that, but you still don’t know which protocols the server is willing to consider.

From: Mike Bishop
Sent: Tuesday, October 17, 2017 9:34 AM
To: 'Patrick McManus' <[email-masked]>; Stefan Eissing <[email-masked]>
Cc: Andy Green <[email-masked]>; Martin Thomson <[email-masked]>; hybi <[email-masked]>; Cory Benfield <[email-masked]>; McManus Patrick <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: RE: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt

From: Patrick McManus [mailto:[email-masked]]
Sent: Tuesday, October 17, 2017 7:34 AM
To: Stefan Eissing <[email-masked]<mailto:[email-masked]>>
Cc: Patrick McManus <[email-masked]<mailto:[email-masked]>>; Mike Bishop <[email-masked]<mailto:[email-masked]>>; Andy Green <[email-masked]<mailto:[email-masked]>>; Martin Thomson <[email-masked]<mailto:[email-masked]>>; hybi <[email-masked]<mailto:[email-masked]>>; Cory Benfield <[email-masked]<mailto:[email-masked]>>; McManus Patrick <[email-masked]<mailto:[email-masked]>>; HTTP Working Group <[email-masked]<mailto:[email-masked]>>
Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt

[...]

-Stefan

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 25 Oct 2017 16:03:10 +1100

Hey Patrick,

Catching up after travel...

The only thing that I don't like about this is covered in your FAQ:

> # Instead of overloading CONNECT, why not a new TUNNEL method?
>
> Methods are generally end to end and, more importantly, HTTP version independent. CONNECT is already a special snowflake in this regard. Note that the only method 7540 defines is CONNECT - because all the others are inherited from the semantic layer of 723x. Extending it is fairly natural as its defined specifically for HTTP/2 while a new method would not be well known as a version specific mechanism.

But 7540 didn't *define* CONNECT, it just adapted how it's used on the wire; the semantics are still "Hey proxy, give me a tunnel to THAT host."

Importantly, CONNECT here isn't being used to talk to a proxy, it's for an origin. And, given how much extra machinery is being defined, I don't see the downside of defining a new method with the specific semantics you're looking for, rather than muddying those of an existing method (which might have bad interactions with current configurations, tools, etc.).

Cheers,

> On 16 Oct 2017, at 1:12 am, Patrick McManus <[email-masked]> wrote:
> 
> FYI - also see https://github.com/mcmanus/draft-h2ws/blob/master/README.md <https://github.com/mcmanus/draft-h2ws/blob/master/README.md>
> 
> To: Patrick McManus <[email-masked] <mailto:[email-masked]>>
> 
> 
> 
> URL:            https://www.ietf.org/internet-drafts/draft-mcmanus-httpbis-h2-websockets-00.txt <https://www.ietf.org/internet-drafts/draft-mcmanus-httpbis-h2-websockets-00.txt>
> Status:         https://datatracker.ietf.org/doc/draft-mcmanus-httpbis-h2-websockets/ <https://datatracker.ietf.org/doc/draft-mcmanus-httpbis-h2-websockets/>
> Htmlized:       https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-websockets-00 <https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-websockets-00>
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-mcmanus-httpbis-h2-websockets-00 <https://datatracker.ietf.org/doc/html/draft-mcmanus-httpbis-h2-websockets-00>
> 
> 
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> The IETF Secretariat
> 
> 

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