Safari 17 Does Not Load WebSockets, TTYD 1.7.4 (ARM) Will Not Load

[hazarjast]

Describe the bug
Safari 17 on macOS Sonoma will not load WebSockets so it cannot connect to TTYD.
The cause seems to be Apple's forcing of the NSURLSession in Safari for WebSocket connections.

To Reproduce
Steps to reproduce the behavior:

1. Execute ttyd to run bash or simple shell script with all ttyd defaults.
2. Attempt to connect to the host running ttyd via IP address.
3. Safari will load only a blank screen with cursor and will continue to load until timeout.

Expected behavior
The full bash or script called by ttyd should load via WebSocket connection.

Screenshots

Environment:

• OS: macOS 14.0 Sonoma
• Browser: Safari 17.0
• TTYD: 1.7.4 (ARM Build)

Additional context
In earlier versions of Safari it was possible to turn off NSURLSession WebSockets but as of 17.0 it is no longer possible to disable as there is no Feature Flag for it. Chrome and Firefox load the session just fine.

[tsl0922]

Then why it is not a Safari bug?

[hazarjast]

I agree that this is a problem Apple created and they should have kept optional support for classic WebSockets in Safari but they have seemingly rejected this path and appear to be imposing their own implementation against the wishes of developers. Looking at the Apple support forums they have consistently pushed back on developer outcry and say in as many words that they have no plans to allow NSURLSession WebSockets to be deactivated from this point forward under macOS/iOS/iPadOS Safari. It seems the issue(s) between NSURLSession WebSockets and TTYD would need to be investigated further to see if a resolution or workaround is possible. If this is not possible at this time, it would be appreciated if the “Supported Browsers” list of TTYD could make mention that the latest versions of Safari are not compatible due to Apple’s changes. This would be less than ideal as I know many Apple users who use TTYD but at least Apple users will not spend a lot of time troubleshooting why they can’t get TTYD to load as expected. Thank you very much for your time and work on TTYD, it is deeply appreciated. I do not possess your level of skills as a developer but if there is anything I can do to help solve this issue I would be happy to try. If you think it is more appropriate that I make this a feature request instead of bug I can certainly resubmit it as such.

…

On Thu, Feb 8, 2024 at 20:30 Shuanglei Tao ***@***.***> wrote: Then why it is not a Safari bug? — Reply to this email directly, view it on GitHub <#1293 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHH3QF5VZBPLTUFH7K7Q773YSV33DAVCNFSM6AAAAABCSB73GKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZVGIYDCNZRGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[tsl0922]

If you can reproduced it with: https://libwebsockets.org/testserver, report it to: https://github.com/warmcat/libwebsockets

[hazarjast]

Yes, I can reproduce by clicking “send junk” option. I can open a bug report for LibWebSockets but maybe the issue is just from what TTYD may be sending to the browser using LibWebSockets and not a bug with LibWebSockets in and of itself? 

…

On Thu, Feb 8, 2024 at 21:41 Shuanglei Tao ***@***.***> wrote: If you can reproduced it with: https://libwebsockets.org/testserver, report it to: https://github.com/warmcat/libwebsockets — Reply to this email directly, view it on GitHub <#1293 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHH3QF3GYZNLACILJZ2IDQTYSWEGVAVCNFSM6AAAAABCSB73GKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZVGI2TGOBYGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[hazarjast]

Looking at other projects which have hit this issue, it seems a workaround may be to disable compression in the WebSocket session: coder/coder#8087 .

Is such a workaround possible with TTYD's use of LibWebSockets? Please let me know if there is anything I can do to help test. Thank you!

I have reported the issue here to LibWebSockets as well, as you indicated: warmcat/libwebsockets#3065 .

[tsl0922]

if you build ttyd with libwebsockets that compiled with LWS_WITHOUT_EXTENSIONS=ON, then ttyd will not use compression.

[hazarjast]

if you build ttyd with libwebsockets that compiled with LWS_WITHOUT_EXTENSIONS=ON, then ttyd will not use compression.

I have used your provided 'cross-build.sh' to compile without extensions as instructed but the resulting TTYD binary shows the same behavior with Safari (i.e. timeout when trying to connect). I notice that on the older Safari versions when it was working the 'Sec-WebSocket-Extensions' listed 'x-webkit-deflate-frame' vs. 'permessage-deflate' which the non-working Safari 17 shows. Not sure if this is significant or not. No movement yet on the bug report submitted to LWS.

[hazarjast]

Spent more time testing this between Safari versions on different configurations and found that Safari 17.x seems to only have issues connecting to an WebSocket session when there is a proxy being used between Safari and TTYD (whether it be SSL or just plain HTTP). On older Safari versions (15.x/16.x/17.x) in this proxy scenario, turning off NSURLSession WebSocket (under 'Experimental Features') allows TTYD to load as expected so there still seems to be some issue between this and LWS. However, since I can get Safari 17.x TTYD connections to work by removing the proxy from my scenario that will work until I can spend more time figuring out why NSURLSession WebSocket under Safari seems to break proxied/tunneled WebSocket sessions.