Bootstrapping WebSockets with HTTP/2
draft-ietf-httpbis-h2-websockets-07
Yes
(Alexey Melnikov)
No Objection
Warren Kumari
(Alissa Cooper)
(Alvaro Retana)
(Deborah Brungard)
(Ignas Bagdonas)
(Martin Vigoureux)
(Suresh Krishnan)
(Terry Manderson)
Note: This ballot was opened for revision 05 and is now closed.
Warren Kumari
No Objection
Adam Roach Former IESG member
Yes
Yes
(2018-06-06 for -06)
Unknown
Thanks to the author and working group for the work that has been done on this mechanism. I have only minor editorial comments. --------------------------------------------------------------------------- General: This document uses the terms "header" and "pseudo-header" in several places where "header field" and "pseudo-header field" is meant. Please find and fix these. --------------------------------------------------------------------------- §1: > HTTP/2 does not allow connection-wide headers and > status codes such as the Upgrade and Connection request headers or > the 101 response code due to its multiplexing nature. Suggestion: "...the 101 (Switching Protocols) response code..." --------------------------------------------------------------------------- §5: > The HTTP/2 stream closure is also analogous to the TCP connection of > [RFC6455]. I think this means to say "TCP connection closure of [RFC6455]." Either that or "...stream handling is analogous to the TCP connection handling of..." --------------------------------------------------------------------------- Section 10.2 seems redundant. Consider removing it.
Alexey Melnikov Former IESG member
Yes
Yes
(for -05)
Unknown
Ben Campbell Former IESG member
Yes
Yes
(2018-06-06 for -06)
Unknown
Just a couple of minor comments: Substantive: §5: Is the scheme pseudo-header expected to match the security status of the existing connection? Editorial: §4, first bullet: This sort of deep link into the IANA registries makes it hard for them to evolve their registry organization over time. Please consider referencing the registry by name.
Alissa Cooper Former IESG member
No Objection
No Objection
(for -05)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -06)
Unknown
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2018-06-05 for -06)
Unknown
Thanks for the well-written document! I only have one comment: should we explicitly mention that the security considerations of RFC 6455 continue to apply?
Deborah Brungard Former IESG member
No Objection
No Objection
(for -06)
Unknown
Eric Rescorla Former IESG member
No Objection
No Objection
(2018-06-06 for -06)
Unknown
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?
Ignas Bagdonas Former IESG member
No Objection
No Objection
(for -06)
Unknown
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -06)
Unknown
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2018-06-06 for -06)
Unknown
One high level question: You say in the intro that a mechanism to transition from http to TCP is needed while the proposed mechanism does actually not "transition" but use websockets OVER http. Was just opening a second TCP connection considered as an alternative?
Spencer Dawkins Former IESG member
No Objection
No Objection
(2018-06-01 for -05)
Unknown
This was mostly clear and easy to understand. I wanted to pass on a few places where I struggled. This is a nit: This tunneled stream will be multiplexed with other regular streams on the connection and enjoys the normal priority, cancellation, and flow control features of HTTP/2. "streams enjoying HTTP/2 features" seems odd to me. Perhaps "has" or even "shares"? But do the right thing. It was really easy for me to read o A new pseudo-header :protocol MAY be included on request HEADERS indicating the desired protocol to be spoken on the tunnel created by CONNECT. without realizing that ":protocol" WAS the pseudo-header - it took me two or three passes to realize that I could stop looking for the pseudo-header, because I'd already seen it. Maybe no one else will be confused? I notice that Section 5 puts scheme names in quotes, and they are more noticeable, so maybe ":protocol" (and the other pseudo-headers in the section) would be helpful to the reader. But do the right thing. I had trouble parsing o 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. somewhere around "does not ever allow to be created" - the combination of passive tense and negation was probably my problem. Even then, "does not allow the creation of" - what? matching text seems to say "the use of a pseudo-header is not allowed to be created". Is that what is intended? If I'm tripping over well-understood HTTP/2 terminology, my apologies, of course. Is there a pointer you could include with this text? The 2017 HTTP Workshop had a very productive discussion that helped determine the key problem and acceptable level of solution complexity.
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -06)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -06)
Unknown