View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005701 | unreal | ircd | public | 2020-06-08 11:34 | 2020-06-08 16:31 |
| Reporter | r4sas | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 4.2.2-rc2 | ||||
| Summary | 0005701: Server cuts long messages instead splitting from some IRC clients | ||||
| Description | I'm runnning a bit old version of UnrealIRCd, but that bug continues from 3.X versions. My server used by russian users, connection listener uses UTF-8 encoding. On android exists old client AndChat which used by some users, and when that send long messages in russian language (and maybe english too), messages cutting on server side after 236 symbols. Sometimes message ends with broken symbol, that looks like that: > ...И разумеется, именно вмес� Sometimes server proceed message till 420 symbol, but codepage brokes in that case. I think UnrealIRCd must correctly determine if message is too long and split it in parts, considering that text in UTF-8. | ||||
| Steps To Reproduce | Connect to server with UTF-8 encoding with AndChat client and send very long text message containing cyrillic symbols, spaces, etc. | ||||
| 3rd party modules | |||||
|
|
Traditionally, it's client's job to prevent this. But i do like the idea of handling this problem at the server side. |
|
|
In IRC, messages can be a maximum of 512 bytes long (called octets in RFC1459) including CR and LF. Whenever a message exceeds this limit it is cut off. This is nothing new, but with UTF8 one symbol/character can be 2 bytes or more, and indeed with Cyrillic it often is 2 bytes, so you are hitting the limit sooner with UTF8 than with old non-UTF8 codepages. Unfortunately, this limit can not be enlarged to more bytes without breaking everything so this is unlikely to happen. As k4be rightly points out, the server will ensure it will never exceed this limit, so if the client doesn't want it to happen then they have to limit their bytes as well. There is a draft IRCv3 proposal at https://ircv3.net/specs/extensions/multiline to make it so you can send more stuff in 1 line. Or, indirectly anyway, because you send 2 lines (or more) that will be glued together as 1 single line for displaying purposes. That still, however, requires the client to keep track of it, having to count bytes, so nothing changes in that area. But the end result will look nicer to clients who would support it. |
|
|
There is also this "solution" by the way: https://defs.ircdocs.horse/defs/numerics.html#err-inputtoolong-417 Which just drops the entire line if a client sends an oversized line (violating basic protocol). But... I don't think that makes anyone happy :) |
|
|
Yes, I understand your opinion about clients, but problem is that AndChat not updated since 2013 (and maybe abadoned), but still one of best-made for android. That's why it still used. So here problem that no-one can fix that but make some support or workaround on server side. |
|
|
Yeah I'm sorry but that is not realistic. I'm going to close this issue as we are not going to do that. The multiline proposal can always be handled in a separate bug report, but it sounds like this would not help you anyway. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-06-08 11:34 | r4sas | New Issue | |
| 2020-06-08 11:38 | k4be | Note Added: 0021609 | |
| 2020-06-08 12:20 | syzop | Note Added: 0021610 | |
| 2020-06-08 12:43 | syzop | Note Added: 0021611 | |
| 2020-06-08 14:55 | r4sas | Note Added: 0021612 | |
| 2020-06-08 16:31 | syzop | Assigned To | => syzop |
| 2020-06-08 16:31 | syzop | Status | new => closed |
| 2020-06-08 16:31 | syzop | Resolution | open => no change required |
| 2020-06-08 16:31 | syzop | Note Added: 0021613 |
