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

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.

On Wednesday, June 6, 2018, Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> 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.
>
>
the PR includes some text


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

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




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

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