Sending a string longer than exactly 44,350 characters over wss:https:// hangs indefinitely in Deno v1.33.0 and greater

[josephrocca]

Very simple to replicate:

// main.js
const ws = new WebSocket('wss:https://bleeding-imagine-scsi-ruled.trycloudflare.com'); // hosting this for ease of replication while this issue is debugged - see instructions below to host your own if needed

ws.addEventListener('open', () => {
  ws.send('a'.repeat(44351));
  console.log('Sent message.');

  ws.addEventListener('message', (event) => {
    if(event.data === 'success') {
      console.log('Got response.');
    }
  });
});

deno upgrade --version 1.33.0 # bug replicates in all later versions too, including latest (1.36.4) and canary
deno run --allow-net main.js

I've only tested on Ubuntu 22.04 - for me it hangs at "Sent message." forever, about 80% of the time. If I drop the string length from 44351 to 44350, it works fine 100% of the time, and it also works fine on versions prior to Deno v1.32.5 and earlier. It also works fine if you paste the above code in the browser console (regardless of string length), of course.

If for some reason it works fine for you (e.g. it could be OS-version dependent), increase the string length to a high number like 1,000,000.

I'm hosting the referenced remote websocket server for ease of replication, but here's the code in case you want to do it yourself. Note that the bug isn't related to the server at all - I've replicated it with Node.js/Python/Deno WebSocket server across various runtime versions.

@bartlomieju @littledivy The above code is a much more minimal replication of the same problem I mentioned here:

• v1.32.4 breaks web sockets #18735 (comment)

Opening a separate issue because the bug seems distinct (different version cut-off), though it is perhaps related.

[bartlomieju]

Thanks for the report 👍 that's very detailed and useful. I assume the problem doesn't happen on ws:https://, only on wss:https://? That would indicate problem in the integration with TLS library on our side.

[josephrocca]

@bartlomieju Yep, that's correct - ws:https:// seems to work fine.

[josephrocca]

@littledivy Apologies for the ping! Wondering if there's any rough ETA on this? I'm completely blocked 🫠

[bartlomieju]

@josephrocca we're still debugging this problem. No ETA yet, but we'll aim to fix it before v1.37.

[josephrocca]

Hey @bartlomieju, any update on this or new (very) rough ETA?

[bartlomieju]

@mmastrac is working on this problem, but I don't know the ETA of the fix. Matt do you have any estimate?

[mmastrac]

There's a few components to this -- first is a fix in our V8 library that may have been causing issues in WebSockets in certain cases denoland/rusty_v8#1326 (fixed).

Second, we need to split the read and write halves of the WebSocket to avoid potential undefined behaviour (denoland/fastwebsockets#48 and #20579).

Third, we need to upgrade our TLS support to a new TLS library here: #20518

This is one of the things I'm actively working on, but I hope that I can get it across the finish line by next week (fingers crossed).

[jflatow]

I'm slightly blocked on #18977 and hoping the fixes here may also address that. Can I help with anything @mmastrac, like testing? It looks like yall merged a websocket change into main not long ago, I'm compiling and will try that version, is it expected to work? Shall I try with mmastrac:tls instead?

[mmastrac]

Early testing on the PR is definitely welcome. I'm currently blocked on my own work upstream in a new TLS library before I can merge this work, but it is possible you may be able to make things work. Backpressure is currently broken on my branch but otherwise should actually work.

Please let me know if that helps

[jflatow]

Unfortunately this alone doesn't fix the #18977 issue 😞

[mmastrac]

I just pushed a new commit to that branch that might help with driving the handshake on writes. We may need to get a test case integrated for this.

[jflatow]

Ah there's a bunch of debugging statements slowing it down (and had to patch up the rebase), but it seems like its actually working 🎉 I can work on getting a test case properly integrated

[josephrocca]

@mmastrac Sorry for the ping again, I was going to ask separately on both #20579 #20518, but I figured I'd just ask about them both here - wondering if there's a very rough ETA on this?

(I tested with --canary just in case it was fixed by denoland/rusty_v8#1326 but the issue is still there)

[mmastrac]

@josephrocca I believe this might be fixed in the next canary. Would you mind re-testing once the canary for b75f3b5 builds?

[josephrocca]

Yep, that fixed it - thank you!!

[caramboleyo]

i still have the secure websocket bug with 1.38.5
it just appears more random now.
sometimes when i enter the page the socket just does not answer anything
if i then do a ping through it after some time it suddenly works
this is still not production ready

[caramboleyo]

funny thing is when it hangs and i send a ping suddenly both responses arrive, the one that was hanging and the pong.
And the hanging messages sent were around 300bytes
the incoming ones about 77 bytes
so it cant be length anymore, just something is holding them back
(now with 1.39.1)