View Issue Details

IDProjectCategoryView StatusLast Update
0002360unrealircdpublic2005-02-22 12:14
ReporterTroco Assigned Tosyzop  
Status resolvedResolutionfixed 
Platformwin32OSXP ProfessionalOS Version5.1 - 2600
Fixed in Version3.2.3 
Summary0002360: charsys synch/link issues
DescriptionThere are some issues related with charsys:
- What happen if two servers with diferent versions (ej: 3.2.2 and 3.2.3) link?
- What happen if two servers with diferent charsets (ej: latinl1 and chinese) link? Network has a big problem: all nicks with special chars are killed.
* An idea would be that if two servers with diferent charset cannot link.
* Another idea would be that if there is a nick with special chars, server send a SVSNICK cutting special chars.
For example:
-> :Trocotronic NICK família
<- :remote.server SVSNICK Trocotronic fam
* More ideas. If two servers with diferent charsets (or versions) both will disable language-accept feature and only allow standar chars.
* Etc.

Obviously there are many solutions, but I think that to kill all users is not the best.
TagsNo tags attached.
3rd party modules



2005-02-20 15:48

administrator   ~0009200

Last edited: 2005-02-20 15:50

I'm not too keen on all these "guess what is right" thingies. While the current way, killing the nicks, is indeed not the best, it would not cause desynchs at least *lol* ;).

Hmm ok.. protoctl is sent before server, perhaps we could check it in protoctl (or store it and check in m_server) and refuse the link in case of a mismatch?

Now if you change charsets afterwards (via /rehash), I really just think "too bad then", since ircops must know what they are doing.. If they are on a turkish net and they delete the turkish charset line then you are just being stupid ;).

*edit* uh ok turkish is not a good example since we don't support that yet, but you get the idea ;p */edit*


2005-02-20 17:33

administrator   ~0009205

Added in CVS [.275].
I'll leave this one open for a few days or so, so you can post any results/problems here :).

[I might be getting a tad unresponsive in the next few days btw, we'll see]


2005-02-20 21:28

reporter   ~0009206

Why do we even check the validity of nicks on remote servers? Shouldn't we just do like the channel system does and just accept whatever the remote server gives us?


2005-02-21 10:50

administrator   ~0009214

Last edited: 2005-02-21 10:52

I don't know ;). If you look at it rationally and compare it to other (lack of) validation things it doesn't make much sense indeed.
For some reason it intuitively feels good however, perhaps because you will have to agree on what characters to allow alltogether? I dunnow :p. Of course this also solves any conflict problems such as half a net with GBK + another half with latin1.


2005-02-21 10:53

administrator   ~0009215

What we could also do is remove the remote validation stuff, but keep the NICKCHARS=..,..,.. thing :). Because we change things in charsets from time to time (due to errors/mistakes), like removing or adding an accent-character for a certain language, which would then cause kills and such.
What about that?


2005-02-21 11:54

reporter   ~0009219

Well, is having one server support Chinese and the rest not really such a bad thing? Like I remember at one point, DALnet restricted all Malaysian users to a single server. Now, for the rest of the network, Malaysian users could not connect. So, in such an instance, wouldn't it make sense to allow the Malaysian characters on the 1 server but not on the rest?


2005-02-21 12:50

administrator   ~0009220

The problem is you can get weird display problems... like (hypotethical), say, I use a certain combination of german/french accent characters... that might be a whitespace nickcharacter(s) in chinese/GBK... by which you can for example hide in the nicklist.
Just as an example, but it's these things that can be pretty problematic.


2005-02-21 12:54

reporter   ~0009221

Yeah, codepages/charsets are fun...


2005-02-22 12:14

administrator   ~0009242

Relaxed remote nick checking in .277 (now it only checks for ascii <=32, and some other characters [like prefixchars]).

Issue History

Date Modified Username Field Change
2005-02-20 15:42 Troco New Issue
2005-02-20 15:48 syzop Note Added: 0009200
2005-02-20 15:49 syzop Note Edited: 0009200
2005-02-20 15:49 syzop Summary charsys issues => charsys synch/link issues
2005-02-20 15:50 syzop Note Edited: 0009200
2005-02-20 16:04 syzop Status new => assigned
2005-02-20 16:04 syzop Assigned To => syzop
2005-02-20 17:33 syzop Note Added: 0009205
2005-02-20 21:28 codemastr Note Added: 0009206
2005-02-21 10:50 syzop Note Added: 0009214
2005-02-21 10:52 syzop Note Edited: 0009214
2005-02-21 10:52 syzop Note Edited: 0009214
2005-02-21 10:53 syzop Note Added: 0009215
2005-02-21 11:54 codemastr Note Added: 0009219
2005-02-21 12:50 syzop Note Added: 0009220
2005-02-21 12:54 codemastr Note Added: 0009221
2005-02-22 12:14 syzop Status assigned => resolved
2005-02-22 12:14 syzop Fixed in Version => 3.2.3
2005-02-22 12:14 syzop Resolution open => fixed
2005-02-22 12:14 syzop Note Added: 0009242