I get a registration timeout on one particular server, and after looking at the /debug output for a while, I finally noticed the problem: Single-item CAP requests are answered with single-item CAP ACK messages, and the final argument of those lines (the actual capability) doesn't start with a colon on this server. So mIRC keeps waiting for a CAP ACK message with a colon, which doesn't arrive because the server sent the CAP ACK messages already and is waiting for mIRC to send a CAP END. Until the registration times out.
So for instance mIRC expects
-> <serverUrl> CAP REQ :multi-prefix
<- <serverUrl> CAP Didero ACK :multi-prefix
but it gets
-> <serverUrl> CAP REQ :multi-prefix
<- <serverUrl> CAP Didero ACK multi-prefix
which mIRC doesn't recognise as a valid CAP ACK message and it therefore ignores the message, and doesn't send a 'CAP END' message, leading to the registration timeout. If I type '/raw CAP END', registration continues normally and I can connect, but obviously the server and the client have pretty different ideas about what the other supports then.
Looking at
the IRCv3 CAP spec, I noticed that in the "The CAP Command" paragraph, it says:
The LS, LIST, REQ, ACK and NAK subcommands may be followed by a single parameter containing a space-separated list of capabilities. If more than one capability is named, the RFC1459 designated sentinel (:) for a multi-parameter argument must be present.
So technically if the CAP ACK message only contains a single capability, it doesn't need a colon, if I read that right.
I know it's a pretty rare problem, and probably a slightly nit-picky one, but I would still really appreciate if it could get fixed.
