250214 - Cannot open private chat with nicks having a "[" or "]" character in them

Status: RESOLVED FIXED

(Other Applications :: ChatZilla, defect)

Description

[Mark Walters]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9

If you attempt to open a private chat with someone who has a "[" or "]"
character in his/her nick, you get the following error:  

[INFO]	Query view for “Polaron-[AFK]” opened.
[INFO]	Now logging to 
<file: **** logfile location removed
***/logs/chatcircuit-com,polaron-%257bafk%257d.log>.
[INFO]	No such nick/channel
---	End of WHOIS information for polaron-{afk}.

At this point, anything you type in the query is not seen by the person who owns
the offending nick.


Reproducible: Always
Steps to Reproduce:
1. right-click a nick such as "Polaron-[AFK]"
2. choose "Open private chat with Polaron-[AFK] (or whomever)
3. The whois error comes up immediately in the query channel.  Nothing you type
will be seen by the other person.

Actual Results:  
I received a whois error "No such nick/channel", and the person to whom I was
trying to send the private message never received it.

Expected Results:  
I should have gotten a valid whois return for the person, and been able to chat
privately.

Comment 1

[James Ross]

This works fine for me, Chatzilla 0.9.64e [Mozilla rv:1.8a2/20040706].

What version of ChatZilla are you using?
What server(s) do you have this problem on?
Does "/query their[nick]" work any better?
Could you copy the output from "/supports", please, or at minimum the entry
"casemapping=" from the "Server settings/limits" (with the value to the right of
the equals!)

I'm guessing that you're on a server that advertising that it's using RFC1459 or
RFC1459-strict CASEMAPPING, and perhaps doesn't actually support it.

I should also note that RFC1459 is the default CASEMAPPING, as per the specs and
historical setup of IRC, so servers that don't use the RPL_ISUPPORT
feature-notification messages, but only support ASCII CASEMAPPING, *will* be
broken and there's little we can do.

Comment 2

[Mark Walters]

The latest version available on the Chatzilla page that I can ascertain is
0.9.64d as far as I can ascertain, released on July 6th.  That's the version I'm
using.  If there is another version posted somewhere, please advise how I can
get it.

Chatzilla 0.9.64d [Mozilla rv:1.7/20040614]

I get the problem on Chatcircuit.com...  
	[INFO]	Server settings/limits: casemapping=rfc1459,
chanmodes=ohvbeqa,kfL,l,psmntirRcOAQKVGCuzNSM, channellen=200, chantypes=#,
chidlen=5, kicklen=307, maxbans=60, maxchannels=10, modes=12, nicklen=30,
prefix=(ohv)@%+, silence=5, topiclen=307, watch=128

and also irc.sorcery.net ....
[INFO]	Server settings/limits: casemapping=rfc1459, chanmodes=b,k,l,Hcimnpst,
channellen=200, chantypes=#&, chidlen=5, kicklen=307, maxbans=60,
maxchannels=10, modes=3, network=SorceryNet, nicklen=17, prefix=(ov)@+,
silence=5, topiclen=307

Comment 3

[Mark Walters]

Also, /query Nick does not work, but yields the same problem.

As a reference, I tried the same thing in mIRC, which worked fine.

Comment 4

[James Ross]

(In reply to comment #2)
> Chatzilla 0.9.64d [Mozilla rv:1.7/20040614]

This is the latest public version.

> Chatcircuit.com, irc.sorcery.net: casemapping=rfc1459

Neither of these servers specify their casemapping in their 005 message, so
ChatZilla defaults to RFC1459 per-spec and historic IRC design. Both these
servers are *actually* using ASCII casemapping. In RFC1459, {} are the
lower-case of [] - this is not true of ASCII.

The problem is that the servers are using a non-standard (i.e. not the default
in the spec, or what IRC historically has used) casemapping but are *not*
telling us.

This is not a bug in ChatZilla - it is working completely correctly.

I would close this INVALID, but I know that wont help. In the case of
Chatcircuit.com, they only need to upgrade their server software to version 3.2,
which correctly tells clients it only uses ASCII casemapping. The real question
is, what do we do, if anything?

  - Trying to get server software updated/changed is futile. I know, because I
tried for ages to get my University's Computing Society to upgrade to Unreal 3.2
so that it worked properly, and didn't get anywhere, despite knowing all the
people involved in person. :)
  - Changing the default to be ASCII instead of RFC1459. Not good, since
historically IRC uses RFC1459 casemapping and anything new enough to use the 005
message has no excuse not to either a) use the RFC1459 casemapping, or b)
advertise what it /does/ use. It also goes against the spec, which would mean
any new servers that used RFC1459 and didn't advertise their casemapping because
it's the default would have problems.
  - Attempt to change the default only for broken servers. I know Unreal IRCD
prior to 3.2 is broken in this regard, and apparently so is
"sor1.3.4.ipv6.chanfix" (what irc.sorcery.net run, looks like their own thing).

(In reply to comment #3)
> As a reference, I tried the same thing in mIRC, which worked fine.

mIRC isn't nearly as smart as ChatZilla, I don't believe it even reads the 005
message at all (I've certainly not heard anyone say it does, or that it does the
{} <--> [] as clients are supposed to, but I've not specifically checked). ;)

Comment 5

[Mark Walters]

Well, mIRC, PIRCH, JIRC, and the javachat page for Sorcerynet may well not be as
smart as Chatzilla... but they all have one thing in common:  They allow me to
open query windows with nicks that have a "[" in them.

You may not consider this to be a bug, but I do.  

I would suggest that since they actually work the way you think they should,
then perhaps they are "smarter" than chatzilla.

I would highly recommend making Chatzilla perform in the same predictable way
that the other chat programs do, whether this is considered a bug or not.

I'm not about to change my chat servers, I don't have control over the software
they're running, but I do have control over the client I use.  And right now,
Chatzilla is deficient, because it won't do something the other clients will.

Please advise if this "non-bug" is ever "non-fixed" so I can go back to using
Chatzilla.

Regards.

Comment 6

[Jesse Ruderman]

It doesn't make any sense that a disagreement with the server over how case
matching works would prevent you from chatting with someone.  Chatzilla should
not be lower-casing the nick as it sends the message.

Comment 7

[James Ross]

(In reply to comment #6)
> It doesn't make any sense that a disagreement with the server over how case
> matching works would prevent you from chatting with someone.  Chatzilla should
> not be lower-casing the nick as it sends the message.

IRC is case-insensitive. ChatZilla always uses the canonical form when
manipulating data and doing server communication. In fact, the IRC server is
pretty much guarenteed to use variable case itself (if you do a whois, the final
reply line uses the same case as the original command, for example).

Comment 8

[Samuel Sieb]

Can we send the actual form instead of lower-casing it?  That would certainly
fix this problem.  We can still accept whatever form is being returned by the
server.

Comment 9

[James Ross]

(In reply to comment #8)
> Can we send the actual form instead of lower-casing it?  That would certainly
> fix this problem.  We can still accept whatever form is being returned by the
> server.

Probably. The question then becomes what else could the server be failing on
because we're sending a canonical form it can't handle? I expect /op, /voice,
etc. will also fail for nicks with []s in them on these particular servers.
That's going to be quite a few places to change, and all for a couple of broken
servers. :)  (I wouldn't object to adding default-exclusions, so we use ASCII
casemapping for these servers, actually)

Comment 10

[Mark Walters]

(In reply to comment #9)
> (In reply to comment #8)
> > Can we send the actual form instead of lower-casing it?  That would certainly
> > fix this problem.  We can still accept whatever form is being returned by the
> > server.
> 
> Probably. The question then becomes what else could the server be failing on
> because we're sending a canonical form it can't handle? I expect /op, /voice,
> etc. will also fail for nicks with []s in them on these particular servers.
> That's going to be quite a few places to change, and all for a couple of broken
> servers. :)  (I wouldn't object to adding default-exclusions, so we use ASCII
> casemapping for these servers, actually)

Are we sure this is only happening on a few broken servers?  When I get a chance
this evening I'll poke around some of the more popular IRC servers and see what
happens.

I can confirm that CTCP, OP, and VOICE commands don't work with a nick with "[]"
on the two servers I use.

I'll do some more investigating and post more information after 10pm Eastern
tonight.

Comment 11

[James Ross]

(In reply to comment #10)
> I'll do some more investigating and post more information after 10pm Eastern
> tonight.

Two months later...

Can someone try ChatZilla 0.9.65?

Comment 12

[Elmar Ludwig]

I can confirm these problems also on irc.euirc.net (which like the already
mentioned servers advertises "casemapping=rfc1459") using Chatzilla 0.9.61.

However, I just upgraded to Chatzilla 0.9.65 (Mozilla 1.8 trunk build) and
no longer see this, at least on euIRC.

Comment 13

[James Ross]

Ok, due to changes made around 0.9.65, all commands use the encodedName to send
commands to the server instead of canonicalName. This means we don't pass the {}
version of [] to servers that *incorrectly* claim to use RFC1459 casemapping (or
don't say what they use).

I'm marking this fixed as it was fixed (AFAIK) by the Unicode nickname support
changes.

If anyone has any specific issues, e.g. certain commands aren't working while
others are, could they please file new bugs as appropriate. If you can reproduce
the problem of private chats not working, please reopen this bug.