I’m seeing what looks like a persistence/parsing bug with saved wss:// server entries in mIRC 7.85.
I use ZNC and have separate saved server entries for normal TLS connections and WSS connections. The WSS entries have unique descriptions/groups, so this does not appear to be caused by duplicate server names.
A typical WSS entry is configured as:
Address: wss://wss.example.com
Port: +443
Password: <ZNC server password>
The entry may work correctly at first, but after reopening/editing/saving it a few times, some or all of the following happen:
- wss:// changes to ws://
- the port falls back to 80
- the password field becomes empty
- the URL/address field becomes corrupted and appears to contain data from the other fields
For example, I have seen it turn into something structurally like:
ws://wss.example.com:+443:<long encoded-looking string>
I have redacted the final value because it appears to be related to the stored/encoded password.
Once the entry gets into this state, connecting can also result in ZNC reporting an incorrect password, despite the password having been entered correctly beforehand.
Recreating the entry from scratch sometimes works, and after several attempts I can usually get a stable entry that connects successfully.
Reproduction
1. Open Options → Connect → Servers
2. Create a new server entry
3. Use an address such as:
wss://wss.example.com
4. Set the port to:
+443
5. Enter a server password
6. Save the entry
7. Reopen the entry and/or edit/save it a few times
Eventually, in my case, the saved values may become corrupted:
wss:// → ws://
+443 → 80
password field → empty
and the address may look similar to:
ws://wss.example.com:+443:<encoded data>
Expected
The saved entry should remain:
wss://wss.example.com
+443
<original password>
across repeated edits/reopens.
Actual
The WSS scheme, port and password appear to sometimes be parsed/serialized into the wrong fields.
Additional observations
- This happens even after giving the WSS entries unique descriptions and groups.
- The corresponding WSS connection itself works when the server entry has been saved correctly.
- The issue therefore appears to be in the saved-server entry handling rather than the actual WSS transport.
- I am using ZNC server passwords, so the password field is populated.
- The corruption looks particularly suspicious because the malformed URL can contain both +443 and a long encoded-looking value that resembles stored authentication data.
Last edited by fauxpride; 28/09/26 08:25 AM.
