- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 27 Oct 2017 10:07:32 +1100
- To: John Fallows <john.fallows@kaazing.com>
- Cc: Patrick McManus <pmcmanus@mozilla.com>, hybi <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CABkgnnVnotgrOBE2o=mi7BxvLEK3MGt_Rr3vmwnLtZ=5VpaOow@mail.gmail.com>
I think that John is right here. Packing the websocket handshake into DATA frames is more complicated than just using the headers. The main difference then between this handshake and the websockets one is: * it's HTTP/2 * it might use a different method (CONNECT or TUNNEL rather than GET) * it uses :protocol instead of Upgrade I still lean toward CONNECT for this, despite reservations about the subtle difference between usages (proxy vs. origin). A natural lightweight implementation of this has the server add proxy code that forwards the tunnel to a websocket server. That proxy would need to perform the old-school 6455 handshake with the websocket server, but could construct that from the headers of the CONNECT request. The handling of the header might be different, but the DATA frames are handled just like a CONNECT tunnel. That said, there is enough difference here to justify a different method. If you do use CONNECT, then you can define a default for :protocol of "tcp" so that there is some sort of regularity to the overall structure and people can build properly generic routing. One thing that using :protocol suggests to me is that we need a new status code for this, just in case someone asks for an unsupported protocol. And you probably want a registry for :protocol values (yay). On Fri, Oct 27, 2017 at 8:47 AM, John Fallows <john.fallows@kaazing.com> wrote: > Hi Patrick, > > Many thanks for spearheading this latest effort to define WebSocket over > HTTP/2, it's really encouraging to see the progress. > > I recall from the early days of the WebSocket protocol design, probably > around the time we moved it from W3C HTML5 to IETF HyBi, that the client > handshake required sending additional content after the GET w/ Upgrade > HTTP/1.1 request. > > This approach led to increased implementation complexity because the > HTTP/1.1 layer on the server now needed to know how to special case the > WebSocket usage of GET. It was also a bit trickier than desired because > that special case processing of GET now spanned over headers and some > initial content. > > Ultimately, that approach was dropped in favor of a single > request-response to define the WebSocket handshake over HTTP/1.1, with no > additional request payload needed to process the handshake, making the > implementation simpler and with better abstraction layering. > > The current proposal for WebSocket over HTTP/2 seems to be following a > similar approach to that described above at the moment, with the HEADERS > frame (requiring special-case processing of CONNECT) and first DATA frame > both needed to process the server-side WebSocket handshake over HTTP/2. > > Suggest we instead fold the origin and relevant RFC-6455 defined HTTP > headers into the HEADERS frame for simplicity, recognizing as Mark noted > that CONNECT is not really intended for use directly at the origin server, > and instead use a TUNNEL method with corresponding :protocol > pseudo-header, where the value of the TUNNEL :protocol pseudo-header > drives the expectation of additional HTTP/2 headers that should be present. > > [[ From Client ]] [[ From Server ]] > > SETTINGS > ENABLE_TUNNEL_PROTOCOL = 1 > > HEADERS + END_HEADERS > :method = TUNNEL > :protocol = websocket > :scheme = https > :path = /chat > :authority = server.example.com:443 > origin = http://www.example.com > sec-websocket-protocol = chat, superchat > sec-websocket-version = 13 > > HEADERS + END_HEADERS > :status = 200 > sec-websocket-protocol = chat > > DATA > WebSocket Frames > > DATA + END_STREAM > WebSocket Frames > > DATA + END_STREAM > WebSocket Frames > > Note also that the scheme is "https" rather than "wss" because the HTTP > request is still "https" until *after* the TUNNEL has been established, and > the TUNNEL protocol being selected is based on :protocol header rather > than the :scheme header. > > Hope this is helpful and interested to hear your thoughts and feedback. > > Kind Regards, > John Fallows > CTO, Kaazing > > On Thu, Oct 26, 2017 at 10:32 AM Patrick McManus <pmcmanus@mozilla.com> > wrote: > >> This is an updated based on the direction discussed.. I'm kind of on the >> fence about whether its better. Its nice there is no h1 in there. >> >> ---------- Forwarded message ---------- >> From: <internet-drafts@ietf.org> >> Date: Thu, Oct 26, 2017 at 1:30 PM >> Subject: New Version Notification for draft-mcmanus-httpbis-h2- >> websockets-01.txt >> To: Patrick McManus <mcmanus@ducksong.com> >> >> >> >> A new version of I-D, draft-mcmanus-httpbis-h2-websockets-01.txt >> has been successfully submitted by Patrick McManus and posted to the >> IETF repository. >> >> Name: draft-mcmanus-httpbis-h2-websockets >> Revision: 01 >> Title: Bootstrapping WebSockets with HTTP/2 >> Document date: 2017-10-26 >> Group: Individual Submission >> Pages: 9 >> URL: https://www.ietf.org/internet- >> drafts/draft-mcmanus-httpbis-h2-websockets-01.txt >> Status: https://datatracker.ietf.org/ >> doc/draft-mcmanus-httpbis-h2-websockets/ >> Htmlized: https://tools.ietf.org/html/draft-mcmanus-httpbis-h2- >> websockets-01 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-mcmanus- >> httpbis-h2-websockets-01 >> Diff: https://www.ietf.org/rfcdiff? >> url2=draft-mcmanus-httpbis-h2-websockets-01 >> >> Abstract: >> This document defines a mechanism for running the WebSocket Protocol >> [RFC6455] over a single stream of an HTTP/2 connection. >> >> >> >> >> 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. >> >> The IETF Secretariat >> >> >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >> > -- > *John Fallows* > CTO* | *📞+1.415.215.6597 > *----------------------------------------------------------------------* > KAAZING >|< when real-time matters™ > kaazing.com/kwic <http://www.kaazing.com/kwic> | Blog > <http://blog.kaazing.com/> | Twitter <https://twitter.com/kaazing> >
Received on Thursday, 26 October 2017 23:08:01 UTC