- From: Andy Green <andy@warmcat.com>
- Date: Sun, 11 Mar 2018 16:34:51 +0800
- To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>, Bence Béky <bnc@chromium.org>
- Cc: HTTP <ietf-http-wg@w3.org>
On 03/11/2018 04:29 PM, Tatsuhiro Tsujikawa wrote: > Hi, > > On Sat, Mar 10, 2018 at 4:14 AM, Bence Béky <bnc@chromium.org > <mailto: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 <http://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 <http://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 <http://nghttp2.org:443> > Origin: https://nghttp2.org > """ Does your proxy stuff test WS CLOSE frames? Because I also have it working except the browser doesn't seem to see the ws CLOSE reason. I'm not sure if that's my problem, but I do seem to send the encapsulated CLOSE frame. > 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 <http://nghttp2.org:443> from Host header > field, and nghttp2.org <http://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 <http://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. I don't have any opinion about that but IMHO it would be good if there was a way you could understand that ws-over-h2 was in use from JS inside the browser. -Andy > Best regards, > Tatsuhiro Tsujikawa > > > > On Thu, Mar 8, 2018 at 7:10 PM, Andy Green <andy@warmcat.com > <mailto: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/draft-ietf-httpbis-h2-websockets-00 > <https://tools.ietf.org/html/draft-ietf-httpbis-h2-websockets-00> > <https://tools.ietf.org/html/draft-ietf-httpbis-h2-websockets-00 > <https://tools.ietf.org/html/draft-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 > <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 08:35:48 UTC