Subject: Working Group Last Call: Bootstrapping WebSockets with HTTP/2

From: Mark Nottingham <[email-masked]>
Date: Thu, 29 Mar 2018 08:48:28 +1100

Hi everyone,

Patrick (as editor) has incorporated the discussion from London and believes this is ready for WGLC; there are no open issues.

Please have a look at:
  https://tools.ietf.org/html/draft-ietf-httpbis-h2-websockets-01

... and bring up any issues on-list or on its issues list; likewise statements of support (or otherwise) for publication on-list would be appreciated.

WGLC will end on 12-4-2018.

Cheers,

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

---

From: Andy Green <[email-masked]>
Date: Thu, 29 Mar 2018 06:24:08 +0800

> ... and bring up any issues on-list or on its issues list; likewise statements of support (or otherwise) for publication on-list would be appreciated.

It's good to go for me... server side is implemented in lws and 
confirmed with Chrome 67, a public server is enabled at 
https://libwebsockets.org/testserver ... if you see [WSS H2] and [HTTP 
H2] icons in the top right it's using it.  I expect to add client side 
of it to lws shortly too.

-Andy

---

From: Mike Bishop <[email-masked]>
Date: Wed, 28 Mar 2018 22:43:48 +0000

I'm supportive of the general idea of the draft.  It feels like it's been a pretty short period to have it adopted, but perhaps that's okay since the draft itself is relatively straightforward.

Some bookkeeping discussion:

  *   Section 4 says that CONNECT is defined in RFC 7540, Section 8.3, which isn't quite accurate.
     *   7540 just has the description of how CONNECT gets mapped into HTTP/2's framing layer, because it's not quite the same as other methods.  This document probably doesn't need to actually modify 7540, because it's employing the extension framework defined therein.
     *   The CONNECT method itself is actually defined in 7231, section 4.3.6.  You're changing how the authority is interpreted in these requests; are we sure this doesn't need to be marked as modifying 7231?
  *   Section 5 "replaces the GET based request in [RFC6455]" and makes other modifications to the requirements contained therein. This seems to suggest that it updates RFC6455 as well.

Random thoughts:

  *   This really is a protocol switch.  Part of me wants the successful response to be 101, because you are employing a different protocol on that stream.

I have a few editorial nits, but I'll send a PR for those.

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]]
Sent: Wednesday, March 28, 2018 2:48 PM
To: HTTP Working Group <[email-masked]>
Cc: Patrick McManus <[email-masked]>
Subject: Working Group Last Call: Bootstrapping WebSockets with HTTP/2

Hi everyone,

Please have a look at:

Cheers,

--

---

From: Bence Béky <[email-masked]>
Date: Thu, 29 Mar 2018 11:38:35 -0400

Hi,

I would like to propose to add some language to the specification about
END_STREAM flag on DATA frames.  The example in Section 5.1
<https://tools.ietf.org/id/draft-ietf-httpbis-h2-websockets-01.html#rfc.section.5.1>
indicates END_STREAM on the last DATA frames, but these is no other mention
of this flag.  Chromium's implementation currently does not set the
END_STREAM flag on any DATA frames sent, but instead resets the stream when
it's destructed, which I do not believe is the most elegant approach.

Something along the lines of "Peers MUST set the END_STREAM flag (defined
in RFC7540 Section 6.1) on any DATA frame sent that contains the entirety
of or the last fragment of a WebSocket Close frame (defined in RFC6455
Section 5.5.1).", appended to the end of Section 5, just above 5.1.

RFC6455 Section 5.5.1 <https://tools.ietf.org/html/rfc6455#section-5.5.1>
states that "The application MUST NOT send any more data frames after
sending a Close frame.", which aligns well with HTTP/2 stream states
<http://httpwg.org/specs/rfc7540.html#StreamStates>, so this feels like the
natural thing to do.

Cheers,

Bence

On Wed, Mar 28, 2018 at 5:48 PM, Mark Nottingham <[email-masked]> wrote:

> Hi everyone,
>
> Patrick (as editor) has incorporated the discussion from London and
> believes this is ready for WGLC; there are no open issues.
>
> Please have a look at:
> ... and bring up any issues on-list or on its issues list; likewise
> statements of support (or otherwise) for publication on-list would be
> appreciated.
>