Re: Chrome experimental support for WebSockets over HTTP/2

On 03/12/2018 02:28 AM, Bence Béky 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.

Please don't worry about that... I traced it to my not realizing 
END_STREAM flag when I send the last encapsulated ws frame is not 
enough, I have to also RST_STREAM.  Then as far as it goes, on my PC, 
the lws test server is working all on one socket :-)  Very nice.

However I met an instability in chrome canary.  If I either run my 
server under valgrind, or run it on ESP32, Chrome on Win 10 will crash, 
the whole app disappears.

An example of the crash is uploaded as crash id bdbb8e6f4d275a10.  I am 
not sure it has anything to do with the ws-over-h2 support though... if 
I dump my outgoing packets with and without valgrind, a) diffing them 
reveals no difference in what we send either way, and b) it changes the 
behaviour in chrome such that it reports "Failed to load resource: 
net::ERR_SPDY_PROTOCOL_ERROR" when the server is h2, not SPDY.  Removing 
the dumps makes Chrome die again, so some kind of race I guess.

Anyway great job, I can get some confidence the code on my side is 
basically working too.

-Andy

> Cheers,
> 
> Bence
> 
> On Sun, Mar 11, 2018 at 4:29 AM, Tatsuhiro Tsujikawa 
> <tatsuhiro.t@gmail.com <mailto:tatsuhiro.t@gmail.com>> 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
>     <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
> 
> 
> 
> 
> 
>

Received on Monday, 12 March 2018 00:58:36 UTC