Re: Chrome experimental support for WebSockets over HTTP/2

Did you use a particular client within Chrome for testing?  I'm using 
the Simple Web Socket Client plugin to test against my server and the 
websocket connection doesn't negotiate h2 via ALPN and continues to use 
HTTP/1.1.



On 03/11/2018 04:29 AM, 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
> """
>
> 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.
>
> 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
>
>
>
>
>

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC