225.45 KB, image/png
6.92 MB, application/octet-stream
973 bytes, application/octet-stream
In case we already have a h2 connection and it does not support websockets, we should not try again to use websockets over h2. r=michal
47 bytes, text/x-phabricator-request
|Details | Review|
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.80 Safari/537.36 Steps to reproduce: * download Firefox 65 beta4 on Linux and started it * Opened this page https://cocalc.com/app?skip_preflight Actual results: * No websocket connection (top right has a connection indicator) * JS console (sorry, german, it says that it can't establish a wss:// connection) > Firefox kann keine Verbindung zu dem Server unter wss://cocalc.com/hub/?_primuscb=MUxYhFa aufbauen. > Die Verbindung zu wss://cocalc.com/hub/?_primuscb=MUxYhFa wurde unterbrochen, während die Seite geladen wurde. Expected results: Just like with Firefox 64 or Chrome, the connection should be established. Additionally, trying to connect via the same way directly to the secret IP address works. Also, this reminds me a lot of https://bugzilla.mozilla.org/show_bug.cgi?id=1453204
Component: Untriaged → Networking: WebSockets
Product: Firefox → Core
I can confirm that Firefox64 works and Firefox65b4 and Firefox66 are generating the error message
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: nobody → dd.mozilla
Status: NEW → ASSIGNED
Priority: -- → P1
I cannot reproduce this. can you make http log for me: https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
second network log file
Hmm, maybe you have to wait a few seconds? the top-right connection indicator is orange while it tries to connect. When it connects that orange goes away. Anyway, I've attached the logfiles that were generated.
I used mozregression-gui which gave me a wrong result in the past but this seems to be correct: >Bug 1434137 - Implement websockets over http/2 - RFC 8441 r=michal,dragana > >https://tools.ietf.org/html/rfc8441 > >This uses our existing http/2 CONNECT infrastructure (modified) to >enable the new extended CONNECT form defined by 8441, and pretend for >the websocket's sake that an http/2 stream is actually a socket. From >the websocket's point of view, this is relatively non-invasive - a few >things have changed (http response code, absence of some headers) versus >http/1.1 websockets, but for the most part, the websocket code doesn't >care.
There are 2 parts of the patch: 1) we should not try to use websockets over h2 if we already know that they are not supported. 2) make sure that we clean up websockets waiting for the settings frame when we close a h2 connection. (the part 1) will fix the issue, this part is only to be 100% that we some how do not retrigger the issue)
What was happening: We try to establish a websocket connection, we find a h2 connection that do not support websockets so we open a new one. The new connection have a tls ticket and can use early-data, so we immediately dispatch the websocket transaction to the new connection and the transaction waits in a queue for the settings frame. At some point we decide to close that h2 connection (because we have another one) and the transactions in the queue are just left hanging... I should also disable 0-rtt for websocket because we will not know if we websockets are supported before connection is established. I will update the patch.
(In reply to Dragana Damjanovic [:dragana] from comment #8) > What was happening: > > We try to establish a websocket connection, we find a h2 connection that do > not support websockets so we open a new one. The new connection have a tls > ticket and can use early-data, so we immediately dispatch the websocket > transaction to the new connection and the transaction waits in a queue for > the settings frame. At some point we decide to close that h2 connection > (because we have another one) and the transactions in the queue are just > left hanging... > > I should also disable 0-rtt for websocket because we will not know if we > websockets are supported before connection is established. I will update the > patch. I forgot that we dispatch all transaction to a h2 connection in ealy-data phase even if they cannot do early-data. We queue them if inside h2 session and websocket transactions will be queued inside h2 session so I do not need to do anything.
Hi Michal, can you please prioritize this review as we're running low on time for uplifts to 65 this cycle? Thanks!
Attachment #9033177 - Flags: approval-mozilla-beta?
You need to log in before you can comment on or make changes to this bug.