Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGeneric websocket error when connecting over WSS using UWP #27043
Comments
|
An interesting experiment is whether this can be reproduced in a desktop UWP app. That would suggest the error lies somewhere in OpenSSL, since the version on macOS and the version used in UWP builds are not necessarily the same. |
|
I have reproduced these errors in desktop UWP. Strangely, enabling the debug logs for websockets doesn't show any new logging output. |
After adding |
|
Looks like there might be a related issue on the ws-rs github: housleyjk/ws-rs#51 |
|
Good find! Also ominous that people keep encountering it except the people best positioned to fix it, apparently :( |
|
So I've been able to create a standalone repro for this issue in this repository. Extra stuffAfter debugging, I've discovered the following: According to the trace listed above and the digging below, it appears that It follows this path:
One weird thing that I've noticed is that Wireshark doesn't show any additional TCP packets once the HTTP requests have completed. This would seem to indicate that maybe we're not connecting to the right place or that the connection could not be made. If that is the case, then the issue may lie in |
|
The next step for minimizing that testcase would probably be to use the |
|
I just updated the repro to use vcpkg to install OpenSSL without servo. |
|
Fantastic write-up in the ws-rs issue. I suspect that mio 0.7 is currently incompatible with UWP, so we may need to switch to a different websocket client library in servo. |
|
@jdm I was literally going to say the same thing! Any suggestions? This one looks kinda cool but I'm not sure what OpenSSL support is required. I'm also assuming that it'd be fine to use the standard library TCP stream API. |
|
https://github.com/snapview/tungstenite-rs/blob/fd7de42347f6b39428bcdb0e7d6a4bf65ccecedb/src/stream.rs#L3-L5 suggests that tungstenite is probably our best choice and should be able to integrate with our existing openssl support in servo. |
|
I've started work to integrate tungstenite in https://github.com/jdm/servo/tree/tungstenite. When attempting to write the code that would support reading and writing independently, I realized that we're going need to add an async layer on top of tungstenite. Possibilties include:
Neither of these options have built-in support for openssl that I can see. While tungstenite works out of the box with any stream that wraps TLS, it looks like we need the equivalent of hyper_openssl to integrate openssl in the async tungstenite ecosystem. Fun times. |
|
Then again, https://github.com/alexcrichton/tokio-openssl and https://gitlab.com/jrobsonchase/openssl-async/-/tree/master look like they might be important missing pieces? |
|
tokio-openssl is actively maintained it seems, so that seems like the best approach for the OpenSSL plumbing if you're using tokio in servo (and not async-std or your own futures runtime). |
Replace ws-rs with async-tungstenite. This change moves us from ws-rs (which doesn't see a lot of maintainer activity) and its custom async implementation to tungstenite and the tokio ecosystem. This is particularly important because of #27043, which breaks SSL websockets on Windows. Depends on sdroege/async-tungstenite#40. --- - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #27043 - [x] There are tests for these changes
Replace ws-rs with async-tungstenite. This change moves us from ws-rs (which doesn't see a lot of maintainer activity) and its custom async implementation to tungstenite and the tokio ecosystem. This is particularly important because of #27043, which breaks SSL websockets on Windows. Depends on sdroege/async-tungstenite#40. --- - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #27043 - [x] There are tests for these changes
Replace ws-rs with async-tungstenite. This change moves us from ws-rs (which doesn't see a lot of maintainer activity) and its custom async implementation to tungstenite and the tokio ecosystem. This is particularly important because of #27043, which breaks SSL websockets on Windows. Depends on sdroege/async-tungstenite#40. --- - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #27043 - [x] There are tests for these changes
|
I have verified that the page loads as expected with #27164 applied. |
Replace ws-rs with async-tungstenite. This change moves us from ws-rs (which doesn't see a lot of maintainer activity) and its custom async implementation to tungstenite and the tokio ecosystem. This is particularly important because of #27043, which breaks SSL websockets on Windows. Depends on sdroege/async-tungstenite#40. --- - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #27043 - [x] There are tests for these changes
Replace ws-rs with async-tungstenite. This change moves us from ws-rs (which doesn't see a lot of maintainer activity) and its custom async implementation to tungstenite and the tokio ecosystem. This is particularly important because of #27043, which breaks SSL websockets on Windows. Depends on sdroege/async-tungstenite#40. --- - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #27043 - [x] There are tests for these changes
Replace ws-rs with async-tungstenite. This change moves us from ws-rs (which doesn't see a lot of maintainer activity) and its custom async implementation to tungstenite and the tokio ecosystem. This is particularly important because of #27043, which breaks SSL websockets on Windows. Depends on sdroege/async-tungstenite#40. --- - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #27043 - [x] There are tests for these changes
Replace ws-rs with async-tungstenite. This change moves us from ws-rs (which doesn't see a lot of maintainer activity) and its custom async implementation to tungstenite and the tokio ecosystem. This is particularly important because of #27043, which breaks SSL websockets on Windows. Depends on sdroege/async-tungstenite#40. --- - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #27043 - [x] There are tests for these changes
|
I can also confirm that is fixed on the Hololens 2. |
Details
I've been having some issues making a secure websockets connection on the Hololens 2. In particular, this webpage (http://yeticgi.casualos.com/?story=test1&pagePortal=home) works fine over HTTP (and WS) but fails to work over HTTPS (and WSS).
All the HTTPS stuff seems to work fine - it's only initiating a connection over secure websockets that is failing. The error message is brief:
When I tried to build with
--features js_backtraceto get some more info, I ran into some issues as documented here: #27042I've also tried loading the same URL with a MacOS build and it worked fine so it seems to be Hololens 2 specific.
Runtime details
OS: Windows Holographic for Business
OS Build:
10.0.19041.1106Servo Version: KallynGowdy@6a5a77a
Build details
OS: Windows 10 Pro
OS Version:
1903OS Version:
18362.900Servo Version: KallynGowdy@6a5a77a
Build Command:
Reproduction steps
path\to\python.exe mach build -d --uwp --win-arm64DefaultUrl.hwithhttps://yeticgi.casualos.com/?story=test1&pagePortal=home.Some things to note:
js_backtracefeature as specified here but I ran into a separate runtime issue detailed here.Logs
Debug Logs