Subject: Eric Rescorla's No Objection on draft-ietf-httpbis-h2-websockets-06: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Wed, 06 Jun 2018 07:55:31 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-httpbis-h2-websockets-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-h2-websockets/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D5180

COMMENTS
S 4.
>         indicating the desired protocol to be spoken on the tunnel created
>         by CONNECT.  The pseudo-header is single valued and contains a
>         value from the HTTP Upgrade Token Registry defined by [RFC7230].
>   
>      o  On requests bearing the :protocol pseudo-header, the :scheme and
>         :path pseudo-header fields MUST be included.

You should say what the path means.

S 4.
>   
>      o  On requests bearing the :protocol pseudo-header, the :authority
>         pseudo-header field is interpreted according to Section 8.1.2.3 of
>         [RFC7540] instead of Section 8.3 of [RFC7540].  In particular the
>         server MUST NOT make a new TCP connection to the host and port
>         indicated by the :authority.

I was sort of able to make sense of this, but it's kind of confusing.
Perhaps you could say a word about it.

S 5.
>      the GET-based request in [RFC6455] and is used to process the
>      WebSockets opening handshake.
>   
>      The scheme of the Target URI [RFC7230] MUST be "https" for "wss"
>      schemed WebSockets and "http" for "ws" schemed WebSockets.  The
>      websocket URI is still used for proxy autoconfiguration.

Just to be clear, you are saying ":scheme" must be https or http?

---

From: Patrick McManus <[email-masked]>
Date: Mon, 11 Jun 2018 15:36:06 -0500

Thanks EKR - I've made a PR to reflect some of these comments at
https://github.com/httpwg/http-extensions/pull/650

It would be helpful to get a review on that text. Responses also inline.

> You should say what the path means.
the PR includes some text

> Perhaps you could say a word about it.

The most common application of :authority (e.g. www.example.com:80) is as
the host and port of the origin on the server to which you are connected..
i.e. I expect this server to be authoritative for www.example.com:80. For
h2 that is section 8.1.2.3 of 7540

The major exception to that (in the absence of this extension) is with the
connect method. In the case of the connect method the :authority is the
host and port that you would like the server to make a TCP proxy connection
to in order to form a tunnel. That's section 8.3 of 7540.

When this extension is negotiated, the rules of 8.1.2.3 apply again on
requests that contain the :protocol pseudo-header. (i.e. connect with
:protocol and this extension creates a tunnel within the server to another
protocol, rather than off the server via a TCP connection).

> Just to be clear, you are saying ":scheme" must be https or http?

Yes, this was a point of considerable discussion on the draft.
Specifically, it was a bit unclear what the scheme was for http/1 (as this
draft did not seek to change that) as http/1 does not state this explicitly
on the wire and 6455 is ambiguous on the point. It was always my belief the
scheme was ws/wss and my first drafts reflected that.. but the WG consensus
was very strong that 6455 did not ever mean to mint a new on the wire
scheme so the draft was updated to clearly document the consensus. (we
reached out to the authors of 6455 somewhat inconclusively, I don't think
the question was squarely addressed at the time or else it would have been
documented in 6455 - and as I say, http/1 allows the ambiguity.)