- From: Patrick McManus <mcmanus@ducksong.com>
- Date: Sun, 11 Mar 2018 21:30:14 +0000 (UTC)
- To: Bence Béky <bnc@chromium.org>
- Cc: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>, Andy Green <andy@warmcat.com>, HTTP <ietf-http-wg@w3.org>
- Message-ID: <CAOdDvNovOTaqKP77ttGorzLP+aidLPpTna5Qw9bUmVPuDjnA1w@mail.gmail.com>
Hey, this is s great to see (as both the author and co-chair). Also, from a Mozilla POV this is great - we're intending to kick off this work very soon so its great to have partners to test with. I think this discussion indicates the example in 5.1 ought to be updated (though both productions with and without the default are legal, so you probably shouldn't do anything different based on it.) On Sun, Mar 11, 2018 at 2:28 PM, Bence Béky <bnc@chromium.org> wrote: > Hi, > > Thank you for feedback. > > Chrome sends the port in the :authority header because the example > in https://tools.ietf.org/html/draft-ietf-httpbis-h2-websockets-00 > Section 5.1 > <https://tools.ietf.org/html/draft-ietf-httpbis-h2-websockets-00#section-5.1> > has the port number. However, Section 4 > <https://tools.ietf.org/html/draft-ietf-httpbis-h2-websockets-00#section-4> > defers to RFC7540 Section 8.1.2.3 > <https://tools.ietf.org/html/rfc7540#section-8.1.2.3> concerning > :authority, which in turn defers to RFC3986 Section 3.2 > <https://tools.ietf.org/html/rfc3986#section-3.2>, where Section 3.2.3 > <https://tools.ietf.org/html/rfc3986#section-3.2.3> explicitly states > default port should be omitted. So I'm happy to omit the default port > number. > > I'll look into the CLOSE frames this coming week. > > Cheers, > > Bence > > On Sun, Mar 11, 2018 at 4:29 AM, Tatsuhiro Tsujikawa < > tatsuhiro.t@gmail.com> wrote: > >> Hi, >> >> On Sat, Mar 10, 2018 at 4:14 AM, Bence Béky <bnc@chromium.org> wrote: >> >>> Hi Andy, >>> >>> It should also work on Android. The command line flag is the same. 67 >>> should trickle down to Dev channel within a week. >>> >>> I'm also anxious to hear if it works. >>> >>> Bence >>> >>> >> I just deployed my reverse proxy server with ws over http2 at >> https://nghttp2.org/echo. >> It forwards websocket request to backend echo server. (path should be >> /echo) >> >> I tested with chrome canary, and it seems to work. I first have to load >> nghttp2.org with h2 otherwise chrome uses HTTP/1.1. Probably it is >> intentional. >> >> One thing I noticed is :authority header field with well known port >> number. Chrome sends request like this: >> >> """ >> :method: CONNECT >> :authority: nghttp2.org:443 >> :scheme: https >> :path: /echo >> :protocol: websocket >> origin: https://nghttp2.org >> """ >> >> And the reverse proxy translates it into HTTP/1.1 request: >> >> """ >> GET /echo HTTP/1.1 >> Host: nghttp2.org:443 >> Origin: https://nghttp2.org >> """ >> >> The websocket echo server I use is echo server from >> https://github.com/gorilla/websocket/tree/master/examples/echo, and it >> compares nghttp2.org:443 from Host header field, and nghttp2.org from >> Origin header field, and it complains because they differ. >> I'm not sure this is standard practice, but I think they do this because >> normally we have "Host: nghttp2.org" in HTTP/1.1 request because 443 is >> default port number for https. >> >> If these practice is widely used, it might be better to drop default port >> number from :authority. The extended CONNECT method is more like regular >> GET because :authority is treated like authority component of target URI >> rather than the remote server which an intermediary should connect to. >> >> Best regards, >> Tatsuhiro Tsujikawa >> >> >> >> >> >>> On Thu, Mar 8, 2018 at 7:10 PM, Andy Green <andy@warmcat.com> wrote: >>> >>>> >>>> >>>> On 03/09/2018 02:16 AM, Bence Béky wrote: >>>> >>>>> Hi folks, >>>>> >>>>> Chrome has experimental support for https://tools.ietf.org/html/dr >>>>> aft-ietf-httpbis-h2-websockets-00 <https://tools.ietf.org/html/d >>>>> raft-ietf-httpbis-h2-websockets-00> starting with release 67 >>>>> (currently only on Canary channel, soon Dev too). One needs to invoke >>>>> Chrome with the --enable-websocket-over-http2 command line flag to enable >>>>> it. The implementation is likely rough around the edges, so I am looking >>>>> for servers to test against. If you are running a publicly available >>>>> server supporting WebSockets over HTTP/2, or have one (or a reverse proxy) >>>>> that I can compile and run locally, please let me know. >>>>> >>>> >>>> I am anxious to try it, but >>>> >>>> Chrome Canary is currently not available on the Linux platform. >>>> >>>> https://www.google.com/chrome/browser/canary.html >>>> >>>> Is the Android build going to allow me to try it (and what's the >>>> equivalent of the commandline flag to enable it if so)? >>>> >>>> -Andy >>>> >>>> Thank you, >>>>> >>>>> Bence >>>>> >>>>> >>>>> >>>>> >>> >> >
Received on Sunday, 11 March 2018 21:30:42 UTC