View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002360 | unreal | ircd | public | 2005-02-20 15:42 | 2005-02-22 12:14 |
| Reporter | Troco | Assigned To | syzop | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | win32 | OS | XP Professional | OS Version | 5.1 - 2600 |
| Fixed in Version | 3.2.3 | ||||
| Summary | 0002360: charsys synch/link issues | ||||
| Description | There 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. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
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* |
|
|
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] |
|
|
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? |
|
|
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. |
|
|
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? |
|
|
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? |
|
|
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. |
|
|
Yeah, codepages/charsets are fun... |
|
|
Relaxed remote nick checking in .277 (now it only checks for ascii <=32, and some other characters [like prefixchars]). |
| 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 |
|
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 |
|
Note Added: 0009219 | |
| 2005-02-21 12:50 | syzop | Note Added: 0009220 | |
| 2005-02-21 12:54 |
|
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 |
