Beta v7.84.1504 changes:
1.Item 8, websocket changes:
mIRC now initially sends:
Sec-WebSocket-Protocol: binary.ircv3.net,text.ircv3.net
If a server replies with a HTTP/1.1 400 Bad Request, mIRC will retry
without Sec-WebSocket-Protocol one more time. If that fails, it
disconnects.
2.Item 9, added.
3.Item 10, added.
4.Item 11, added.
5.Item 12, added.
6.Item 13, added. IRCv3 features like this one require a client to store
per-line meta-data for every client/server message/event. In this case,
mIRC needs to store per-line meta-data for label, msgid, and +reply
for every sent/received message in order to associate related messages.
You can see the label/msgid/+reply values in incoming/outgoing messages
with /debug.
This beta will briefly highlight matching incoming/outgoing messages in
a query/channel window. I am not sure how useful this is - it has been
added as a visual aid to see the way it works. I may or may not keep
it in a final release. It uses your "Highlight" color to tint the
background color of matching messages.
Note: this beta enables echo-message only if labeled-response is
available in CAP. Labeled-response is critical to making echo-message
features work correctly.
Beta v7.84.1235 changes:
1.Item 8, websocket changes:
1) Added Sec-WebSocket-Protocol header to HTTP negotiation.
This beta now requests binary.ircv3.net for binary frames. If I
understand correctly, this should allow the beta to send text
that is not UTF-8 encoded. This allows the Options/Messages/UTF-8
enable/disable option to work and the per server codepage encoding
option to work.
If the server replies with text.ircv3.net, mIRC will ignore its
own UTF-8/codepage settings and will always encode text as UTF-8
and will use text frames.
2) Fixed bug relating to when Winsock cannot immediately send all of
the bytes requested in a send(). This was not being handled
correctly for websocket frames. This change affects non-websocket
connections as well. This issue rarely happens, so I had to
simulate/stress-test it.
3) Framed messages are now stripped of trailing CRLF characters since
the websocket specification says they are not required. Some ircds
strip these out by default but some may just report a malformed
line.
4) Handling embedded CRLF in outgoing messages.
mIRC allows users to embed any number of CRLFs in single messages,
eg. using /msg, /raw, etc. IRC servers just parse these as separate
CRLF delimited messages.
On websocket servers, where each message needs to be framed,
different ircd's behave differently if there are embedded CRLFs in
a line.
When subprotocol text.ircv3.net is used:
1) Some ircds will disconnect / report a malformed line.
2) Some ircds chop the line at the first CRLF and process just the
first part of the line.
3) Some ircds will split at CRLF and treat each line as a separate
message.
When subprotocol binary.ircv3.net is used:
1) Some ircds will disconnect / report a malformed line.
2) Some ircds will strip out CRLFs and treat the whole line as a
single message.
3) Some ircds will split at CRLF and treat each line as a separate
message.
The 3rd behaviour would be ideal for a client for a number of
reasons. However, currently, the only way to achieve consistent
behaviour across irds is:
This beta splits outgoing lines by CRLF before sending them
individually to the server. Technically, on a non-websocket server,
this should make no difference. On a websocket server, each of these
lines will now be in its own frame.
Beta v7.84.1148 changes:
1.Item 1, fixed.
2.Item 2, fixed.
3.Item 3, changed.
4.Item 4, fixed.
5.Item 5, changed. Previous versions did not validate ports entered into
the servers dialog. Entered ports are now parsed, checked, and discarded
if not valid eg. comma separated ports, ranges N-N, + and * prefixes,
and values 1 - 65535, duplicates, etc.
6.Item 6, added.
7.Item 7, updated.
8.Item 8, added websocket support.
Adding Websocket support initially looked like it would be reasonably
straightforward. It ended up snowballing and affecting a large number of
features and required significant work and testing. I attemped several
different approaches and settled on the current implementation.
The aim was to make websocket support as transparent as possible to the
user. Enter a websocket address as a server address, click connect, and
it should just work.
The following items cover the main issues/challenges:
1) Integrating websocket connections into mIRC's existing connection
handling, DNS resolution, and so on.
I had originally planned to use an established, well-tested WebSocket
C/C++ library. However, after trying out several popular libraries,
it became apparent that integrating these into mIRC's own connection
code would be complicated. I ended up implementing my own websocket
code that integrates directly with mIRC's existing socket code with
as few changes as possible to existing code while maintaining the
same sequence of parsing, events, logging, scripting, etc.
You can use "/debug on" to see the initial websocket negotiation. While
this is not technically necessary for debug.log, I wanted to include
it so that we can see that mIRC is attempting a websocket connection.
After the negotiation, messages are extracted from websocket frames and
saved to debug.log, ie. without the websocket frame data, the same as
standard connections.
If mIRC connects to a port that does not support websockets: every
ircd behaves differently. mIRC will always check to see if the first
reply from a server is HTTP. If it is not, it assumes that the message
is a standard IRC server message and defaults to a standard non-websocket
connection. For example, if you try to connect to
ws://testnet.ergo.chat:6667, it will reply with:
:testnet.ergo.chat 400 GET :This is not an HTTP server
And the server will close thc connection. If you try to connect to
ws://testnet.inspircd.org:6667, the server ignores the HTTP negotiation
and replies with NOTICEs. Some servers will disconnect since they treat
the attempted HTTP negotiation as an error.
2) The use/handling of websockets across features.
Websocket addresses use the prefix ws:// for plain connections and
wss:// for secure connections. They can also include a port/path:
wss://testnet.ergo.chat:+443/webirc
The ws:/wss: is problematic because it uses a colon, which many
features parse as a port number separator in the address.
The path is problematic because it means it is no longer just a
hostname and cannot be parsed by the hundreds of features and
functions in mIRC that expect a hostname.
A lot of work went into ensuring that all features continue to see
only see the hostname unless they need the websocket address. The
websocket address is only used in specific situations, such as when
performing the websocket negotiation, editing the address in the
server dialog, etc. In all other situations, eg. DNS resolution,
GUI display, etc. it is just a hostname.
For scripts, this is also a tricky issue, eg.
a) $server continues to return a hostname since its value is
dependent on a hostname that can change during the connection
process, eg. round-robin address changes to actual address once
connected and numeric is received.
b) $servertarget now returns the websocket address if set.
c) $server().addr now returns the websocket address if set.
d) Other features should continue to return a hostname.
3) Server address cycling.
If you try to connect to a server address, mIRC will look it up in
your servers list, find its group name, and cycle through the list of
servers/ports for that group.
Nowadays, servers.ini only includes a single round-robin address per
network, however the server cycling process is still in place.
I have had to update a number of routines to match on the websocket
address instead, if one is defined for a server/connection.
4) Handling port numbers.
If you enter the above websocket address into the address editbox in
the servers dialog and then press the OK or tab key:
a) The ws:/wss: prefix will be removed as it is not needed and
conflicts with the port editbox settings for SSL/non-SSL which
can contain a list of ports.
b) The port number will be automatically extracted and placed into
the ports editbox. A port in the address will always override any
items in the ports editbox.
c) If no port is specified, a default of 80/+443 is used. The 80/+443
port default is used in many contexts if a websocket is in use
instead of the standard 6667/+6697 default.
5) Storing websocket addresses in servers.ini.
I tested several methods, some of which preserved ws:/wss:, or stored
the websocket address/path as a separate item. I eventually settled on
the format described below.
n1=Random serverSERVER://testnet.ergo.chat/webirc:+443GROUP:Ergo
The ws:/wss: prefixes are removed because 1) their use of a colon
breaks backward compatibility with older vesions of mIRC which will
mangle servers.ini if it is used, and 2) they conflict with the
port number setting which can be a list of SSL/non-SSL ports.
The prefix // is used to identify a connection as a websocket.
Storing/parsing IPv6 addresses was another complication. mIRC will parse
IPv6 addresses, adding/removing [] brackets in different contexts as
needed, eg. brackets are needed during HTML negotiation, they are not
needed when connecting a socket, and so on.
6) Handling ws:/wss: as chat links.
These are now registered and handled by mIRC, just like irc:/ircs:, and
ws:/wss: are now also parsed on the command line.
7) Parsing of IRC numeric 10 now checks for ws:/wss: links, so a server can
redirect a client to a websocket connection if it needs to.
8) STS/SSL Cache/etc.
The SSL cache continues to use the host name as this is taken from the
SSL certificate.
The STS port is saved using the websocket address, which needs to match
against the websocket/non-websocket connection type.
Websocket support required changes to 50+ files relating to everything from GUI,
scripts, connections, port handling, address parsing, in addition to the new
code for websocket handling. It has been tested using InspIRCd locally and with
the following websocket servers:
wss://testnet.inspircd.org:8097
wss://testnet.ergo.chat/webirc
wss://irc.unrealircd.org
As this is the first release with websocket support, and it has been through
many iterations/changes, there will likely be bugs. Please let me know if you
spot any issues.
Changes:
1.Fixed display of numeric 344 whois reply on InspIRCd.
2.Fixed various issues relating to 64-bit/ARM64 in preparation for a
future 64bit release.
3.Changed STS support to allow previously accepted invalid certificate.
4.Fixed hotlink parsing to strip trailing . periods from an address.
5.Changed how server ports are parsed to ensure that only valid port
number formats/ranges/prefixes are accepted.
6.Added Alt+D key combination to the Connect dialog that allows you to
delete a server easily but with a confirmation dialog.
7.Updated libraries to TagLib v2.3.1.
8.Added support for WebSocket connections. You can now enter a websocket
address, prefixed with ws: or wss:, as a server address and mIRC will
connect to that server using websockets.
9.Added IRCv3 EXTBAN/ACCOUNTEXTBAN support to /ban and $ibl().
Added /ban -a switch that will check the IAL for a nick's account
name and will apply the EXTBAN/ACCOUNTEXTBAN prefixes to ban/unban
the account. If no account is found, it applies a wildcard ban.
Add $ibl() properties .prefix, .mask, and .account which parse and
return values relating to the banned address/account. The .account
property uses the ACCOUNTEXTBAN prefixes to identify and extract the
account name.
10.Added /server -ircv3 [tokens] switch that allows you to set
no-implicit-names[=0|1] when connecting to a server. This setting
remains in place for a status window until changed.
11.Added support for IRCv3 context-chan message tag. When a message has
this tag, PRIVMSG and NOTICE will be re-routed to that channel, but
only if existing settings and/or open windows do not override it.
12.Added support for display of numerics 697/698 in channel window.
13.Added support for IRCv3 +reply. In a channel window, if you prefix a
message with "nick:" and the last message from that nick has a msgid,
your message will use that msgid in +reply when it is sent. mIRC will
also check received messages for +reply and will briefly highlight
related messages in the same window.
