Subject: I-D Action: draft-ietf-httpbis-h2-websockets-03.txt

From: [email-masked]
Date: Wed, 02 May 2018 14:05:50 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Hypertext Transfer Protocol WG of the IETF.

        Title           : Bootstrapping WebSockets with HTTP/2
        Author          : Patrick McManus
	Filename        : draft-ietf-httpbis-h2-websockets-03.txt
	Pages           : 7
	Date            : 2018-05-02

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

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-h2-websockets/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-httpbis-h2-websockets-03
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-h2-websockets-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-h2-websockets-03

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Patrick McManus <[email-masked]>
Date: Wed, 02 May 2018 21:15:23 +0000 (UTC)

Hey All -

First, sorry for the churn of publishing -03 and -02 back to back.. I had
fixed a typo as my last change but failed to add it to the repo (left it on
a local branch) before pushing -02.. as I hope this is the LC copy, I
wanted to get it in there. At least we don't have an ID numbering tax
(yet?).

Anyhow - -03 reflects the resolution of WGLC discussion as best as I can
manage..

-P

---

From: Biren Roy <[email-masked]>
Date: Wed, 02 May 2018 22:26:40 +0000

Not related to the latest draft text, but regarding Websockets over HTTP/2
generally: we recently discovered that versions of the okhttp client
library before 3.1.0 would send a GOAWAY upon receiving an unknown setting
ID. This is causing us some difficulty as we attempt to perform
interoperation tests with our implementation.

I've heard a few people suggest that we try something like GREASE
<https://tools.ietf.org/html/draft-ietf-tls-grease-00> for HTTP/2 settings,
to expose this type of bug sooner.

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 2 May 2018 23:04:15 +0000

IMO GREASE was targeted a middleboxes that made assumptions about the way some bit spaces were used. As an endpoint operator it is difficult to influence such boxes.

Incorrectly handling H2 settings is unfortunate but solely in the realm of endpoints. It's non-compliance and should be fixed.

A similar class of problems were found with (I think) some python implementations around the handling of 1xx status codes. The approach was to fix them.

Regards
Lucas
________________________________________
From: Biren Roy [[email-masked]]
Sent: 02 May 2018 23:26
To: Patrick McManus
Cc: HTTP Working Group
Subject: Re: I-D Action: draft-ietf-httpbis-h2-websockets-03.txt

Not related to the latest draft text, but regarding Websockets over HTTP/2 generally: we recently discovered that versions of the okhttp client library before 3.1.0 would send a GOAWAY upon receiving an unknown setting ID. This is causing us some difficulty as we attempt to perform interoperation tests with our implementation.

I've heard a few people suggest that we try something like GREASE<https://tools.ietf.org/html/draft-ietf-tls-grease-00> for HTTP/2 settings, to expose this type of bug sooner.

On Wed, May 2, 2018 at 5:24 PM Patrick McManus <[email-masked]<mailto:[email-masked]>> wrote:
Hey All -

First, sorry for the churn of publishing -03 and -02 back to back.. I had fixed a typo as my last change but failed to add it to the repo (left it on a local branch) before pushing -02.. as I hope this is the LC copy, I wanted to get it in there. At least we don't have an ID numbering tax (yet?).

Anyhow - -03 reflects the resolution of WGLC discussion as best as I can manage..

-P

On Wed, May 2, 2018 at 5:05 PM, <[email-masked]<mailto:[email-masked]>> wrote:

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 02 May 2018 23:56:26 +0000

Grease was definitely aimed a faulty servers as well.  There were a couple
of implementations of TLS that choked on new signature algorithms and -
from memory - named groups.  These were the direct motivation for the
grease design.

Sad news about okhttp.
On Thu, May 3, 2018 at 9:13 AM Lucas Pardue <[email-masked]> wrote:

> IMO GREASE was targeted a middleboxes that made assumptions about the way
some bit spaces were used. As an endpoint operator it is difficult to
influence such boxes.

> Incorrectly handling H2 settings is unfortunate but solely in the realm
of endpoints. It's non-compliance and should be fixed.

> A similar class of problems were found with (I think) some python
implementations around the handling of 1xx status codes. The approach was
to fix them.

> Not related to the latest draft text, but regarding Websockets over
HTTP/2 generally: we recently discovered that versions of the okhttp client
library before 3.1.0 would send a GOAWAY upon receiving an unknown setting
ID. This is causing us some difficulty as we attempt to perform
interoperation tests with our implementation.

> I've heard a few people suggest that we try something like GREASE<
https://tools.ietf.org/html/draft-ietf-tls-grease-00> for HTTP/2 settings,
to expose this type of bug sooner.

manage..

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 3 May 2018 10:21:48 +0900

Hello Patrick,

> wanted to get it in there. At least we don't have an ID numbering tax

Burning draft numbers is an well-honored tradition for WebSockets (see
https://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-76), so you 
are in good company :-).

Or should we say you still have a long way to go :-?

Regards,    Martin.

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 3 May 2018 08:39:18 +0000

Hmm, quite right. So let me backtrack a bit...

I think the principle of greasing, as opposed to the specific TLS mechanism, could be justified to avoid HTTP/2 and HTTP/QUIC extension mechanism problems.

So this is not just settings but extension frames too. The tricky part is that they are not "negotiated", and work bidirectionally. So a slightly different approach than TLS is probably required. 

Tangentially, Alt-Svc parameters may suffer from extensibility problems too.

Lucas
________________________________________
From: Martin Thomson [[email-masked]]
Sent: 03 May 2018 00:56
To: Lucas Pardue
Cc: Biren Roy; Patrick McManus; HTTP Working Group
Subject: Re: I-D Action: draft-ietf-httpbis-h2-websockets-03.txt

Sad news about okhttp.

manage..

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 3 May 2018 07:15:52 -0700

I would definitely support carving out a chunk of the settings codepoints
for GREASE'd values and allowing/requiring endpoints to randomly send
values for them.

---

From: Kari Hurtta <[email-masked]>
Date: Thu, 3 May 2018 21:38:01 +0300 (EEST)

5.  Using Extended CONNECT To Bootstrap The WebSocket Protocol
https://tools.ietf.org/html/draft-ietf-httpbis-h2-websockets-03#section-5

|   [RFC6455] requires the use of a Host header which is also not part of
|   HTTP/2.  The Host information is conveyed as part of the :authority
|   pseudo-header which is required on every HTTP/2 transaction.

RFC 7540

8.1.2.3.  Request Pseudo-Header Fields
https://tools.ietf.org/html/rfc7540#section-8.1.2.3

requirements is little more complex:

|      To ensure that the HTTP/1.1 request line can be reproduced
|      accurately, this pseudo-header field MUST be omitted when
|      translating from an HTTP/1.1 request that has a request target in
|      origin or asterisk form (see [RFC7230], Section 5.3).  Clients
|      that generate HTTP/2 requests directly SHOULD use the ":authority"
|      pseudo-header field instead of the Host header field.  An
|      intermediary that converts an HTTP/2 request to HTTP/1.1 MUST
|      create a Host header field if one is not present in a request by
|      copying the value of the ":authority" pseudo-header field.

Regurement if :authority is just "SHOULD". So it is NOT
required on every HTTP/2 transaction. That also can be Host
header instead.

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: Thu, 3 May 2018 22:03:07 +0300 (EEST)

( Also https://lists.w3.org/Archives/Public/ietf-http-wg/2017OctDec/0261.html )

This should mention that :status = 200 replaces status code 101
used on RFC 6455, section 1.3.

1.3.  Opening Handshake
https://tools.ietf.org/html/rfc6455#section-1.3

"   The handshake from the server is much simpler than the client
"   handshake.  The first line is an HTTP Status-Line, with the status
"   code 101:
"
"        HTTP/1.1 101 Switching Protocols
"
"   Any status code other than 101 indicates that the WebSocket handshake
"   has not completed and that the semantics of HTTP still apply.  The
"   headers follow the status code.

8.1.1.  Upgrading from HTTP/2
https://tools.ietf.org/html/rfc7540#section-8.3

"   HTTP/2 removes support for the 101 (Switching Protocols)
"   informational status code ([RFC7231], Section 6.2.2).
"
"   The semantics of 101 (Switching Protocols) aren't applicable to a
"   multiplexed protocol.  Alternative protocols are able to use the same
"   mechanisms that HTTP/2 uses to negotiate their use (see Section 3).

Not it is only on

5.1.  Example
https://tools.ietf.org/html/draft-ietf-httpbis-h2-websockets-03#section-5.1

/ Kari Hurtta

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 4 May 2018 12:22:43 +1000

Thanks, Patrick.

It looks to me like -03 addresses all of the WGLC feedback as well. I'll start the Shepherd writeup and submit to the IESG for processing.

Thanks everyone for your work on this, and especially Patrick for pushing it through.

Cheers,

> On 3 May 2018, at 7:15 am, Patrick McManus <[email-masked]> wrote:
> 
> Hey All - 
> 

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

---

From: Patrick McManus <[email-masked]>
Date: Fri, 04 May 2018 02:26:44 +0000 (UTC)

Thanks. It has an I'd niit to fix but starting the write-up wfm.

On Thu, May 3, 2018, 22:22 Mark Nottingham <[email-masked]> wrote:

> Thanks, Patrick.
>
> It looks to me like -03 addresses all of the WGLC feedback as well. I'll
> start the Shepherd writeup and submit to the IESG for processing.
>
> > First, sorry for the churn of publishing -03 and -02 back to back.. I
> had fixed a typo as my last change but failed to add it to the repo (left
> it on a local branch) before pushing -02.. as I hope this is the LC copy, I