2019-07-03 21:20:35.838000 UTC - [Parent 23884: Socket Thread]: D/nsSocketTransport nsSocketInputStream::Read [this=0000027EFA0CCE68 count=4000]
2019-07-03 21:20:35.838000 UTC - [Parent 23884: Socket Thread]: D/nsSocketTransport calling PR_Read [count=4000]
2019-07-03 21:20:35.838000 UTC - [Parent 23884: Socket Thread]: D/nsSocketTransport PR_Read returned [n=-1]
2019-07-03 21:20:35.838000 UTC - [Parent 23884: Socket Thread]: D/nsSocketTransport ErrorAccordingToNSPR [in=-8179 out=805a1ff3]
2019-07-03 21:20:35.838000 UTC - [Parent 23884: Socket Thread]: D/nsSocketTransport nsSocketTransport::OnMsgInputClosed [this=0000027EFA0CCC00 reason=805a1ff3]
2019-07-03 21:20:35.838000 UTC - [Parent 23884: Socket Thread]: D/nsSocketTransport nsSocketTransport::Close 0000027EFA0CCC00 reason=805a1ff3

We apparently mismatch host name and the cert (we probably verify target against the proxy cert).

Aha, I've observed this behavior...

When the h2 proxy advertises support for RFC 8441 (enableConnectProtocol: true in Node.js), Firefox seems to CONNECT to the proxy server and communicate with it as if it were the actual WebSocket server. The behavior was bizarre, sometimes hanging and sometimes erroring. I didn't investigate further though.

When the proxy does not advertise support for RFC 8441, Firefox instead makes a CONNECT over HTTP/1.1, and then WebSockets work.

Nhi, as this can negatively affect chats, I'm not sure if this is for the skyline target or mvp...

:michal, could you evaluate how much work it is to fix this?

Can you give me STR, so I can reproduce it locally?

I guess the problem might be somewhere in websocket part of HTTP/2 code. Dragana, you did the review of that code in bug 1434137. Could you please have a look at it?

I got some feedback from Andrew Sun on this one in a side-thread. This is likely not needed for the MVP as this can possibly be fixed on the proxy relatively easily. I will look into this more.

Very likely fixable by flipping network.http.spdy.websockets to false.

No, it's not...

I was able to fix this (as suggested by Andrew in a private email thread before) on the proxy side [1] by implementing unknownProtocol handler forwarding to a plain h1 proxy handling plain and CONNECT requests with h1 nodejs api.

[1] https://github.com/mayhemer/node_http2_proxy/commit/666ae086839369e2a86cdecdfa4fcf4500429b80