Re: Chrome experimental support for WebSockets over HTTP/2

Hi,

On Sun, Mar 11, 2018 at 5:34 PM, Andy Green <andy@warmcat.com> wrote:

>
>
> 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.
>
>
​My proxy just transfer bytes between client and backend websocket server
without inspecting ws frames, and if an endpoint sends CLOSE, then proxy
probably forwards it.  The one caveat is timeout case in backend
connection.  If that happens, proxy might just reset a stream, and no CLOSE
frame will be sent.​


> 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-websocket
>> s-00>
>>             <https://tools.ietf.org/html/draft-ietf-httpbis-h2-websocket
>> s-00
>>             <https://tools.ietf.org/html/draft-ietf-httpbis-h2-websocket
>> s-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:45:33 UTC