I’m seeing some strange behavior whenever I open a websocket with wss in the URI instead of ws. It instantly returns an error on open, and refuses to connect. With a standard websocket, it connects just fine.
Any ideas what’s happening or if there’s a feature I’m not taking advantage of?
If not, is this a bug?
Change the websocket url below to “ws://echo.websocket.org” to see a working version.
For this demo, I added this code to the UI kitchen sink to test. Here’s the error object it returns:
Yes; wss is supported. I just tried from a debugging session in Ps, and it worked fine. Perhaps the server was having problems? Or, possibly, you’re behind a proxy? If you log e.message when you get the error, what’s the response?
No proxies here, and the error is an unusual object (screenshot below) with no message.
I just tried again as well and same result. I had a colleague test this same code in his own playground, and he encountered the same error object.
I had another developer in Nevada and one in Cali attempt the same thing. They got the same result (screenshot below).
Is there a way we can get the version of our environment that might help track down if perhaps we’re behind on an update? (Or is it only the Photoshop version we’d need to help debug?)
Corrected screenshot to include e.reason and e.message:
So, your screenshot looks like Windows – and on my Windows machine, I can confirm that the request is failing. I’m not sure why, though – may be something SSL related since the failure is so immediate with so little information.
You might try with your own websocket server to see if you get more information as to the failure. I’ll also forward this along internally, since there may be a bug on our end. This used to work fine, but it may be a regression.
We traced the tcp activity at the server level where the websocket endpoint lives, to see if there was anything unusual going on.
As far as we can tell, the websocket handshake appears to be functioning as expected, and then something inside Ps breaks after, perhaps at the completion of the handshake on open.
Just wanted to provide a little more info to help debug!
It sounds like the initial handshake is working OK, but the transition to websocket protocol is breaking… strange! We do use boringSSL for Windows, so I wonder if there’s something going on in the SSL layer…
Can you make fetch HTTPS requests to the same server without issue? That might provide some leads.
We’ve figured out the root cause of the problem, and there’s nothing you can do on the server side to rectify it. The issue is that the certificate store isn’t getting loaded correctly, and so UXP closes the connection as if it found a certificate it couldn’t validate.
I’ve got the team looking into the fix. I’m hopeful it can be in place for the June release of Ps. Cross your fingers.
If you want to test things out before the fix, there’s a workaround – get your hand on a cert.pem file (Mac or Linux should do) and copy it to C:\etc\ssl\cert.pem. Once done, your WSS connection will start working. This is not a solution for end users, but would unblock things enough to test the rest of the plugin.
It’s fixed as part of UXP 5.1. As to when Ps releases w/ this, that’s a harder question, since it’s up to them when they pick it. Not much longer to wait, though.
If you aren’t already, please join the prerelease. You’ll get a version that works there earlier than the general public. Note, though, that the prerelease is still on 5.0, so don’t get your hopes up just yet.
