Opened 8 years ago

Last modified 4 weeks ago

#4753 new defect

IRC messages silently truncated to first ~500 characters

Reported by: tmetro Owned by: elb
Milestone: Patches Needing Review Component: IRC
Version: 2.3.1 Keywords:
Cc: jankratochvil, kip, Julian, Mehnle, pcworld, azrdev, ollie27


This is the same idea as ticket 3876 regarding Yahoo Messenger ptotocol.

I originally reported this against the IRC Helper plugin here:

but it's really a problem with the core code.

As most IM protocols probably have some message length limitation, unless each is updated to automatically autosplit messages, this probably needs to be addressed in a general way in the UI, where it would limit the size of the text input box to the length specified by the protocol.

Attachments (2)

check-msg-size.diff (1.3 KB) - added by belmyst 2 years ago.
Proposed patch, check packet length before sending
check-msg-size-v2.diff (1.7 KB) - added by belmyst 2 years ago.
Also count server overhead in the check)

Download all attachments as: .zip

Change History (21)

comment:1 Changed 8 years ago by tmetro

This seems to be a duplicate of Ticket #4652, except that ticket reports that Pidgin reports an error when you attempt to send a message that is too long, and in my experience that doesn't least not with IRC.

comment:2 Changed 8 years ago by mandie722

Pidgin does report an error in AIM chat windows. I run into this all the time and it would be nice to have something that would at least warn you when you are exceeding the message size limit for that protocol.

Message appears as follows in the History window:

(4:31:10 PM) Unable to send message: The message is too large.

In the debug window you see:

(16:31:10) oscar: Could not send ..... because (489 > maxlen 2000) or (489 > maxvis 232)

Ideas would be to:

  1. Have a character count on the text input and have it display the max number of characters allowed so you can see when you may have input too much.
  1. Have the text input box stop allowing any further text once you have hit the maximum length.
  1. Split the message into multiple messages of the appropriate length. This could trigger spam alerts though.

comment:3 Changed 8 years ago by aluchko

This issue is a blocker for me to be able to use Pidgin for irc.

Particularly in technical conversations long sections of text can be quite common and I've already been bitten by this bug a few times.

comment:4 Changed 8 years ago by elb

  • Milestone set to Patches welcome

comment:5 Changed 8 years ago by elb

We will get to this eventually, but in the meantime I am moving it to 'patches welcome' because it's a great place for a third-party contributor to step in and help out.

comment:6 Changed 8 years ago by simos

Adding myself to this issue.

comment:7 Changed 8 years ago by jankratochvil

RFC2812 section 2.3:

Thus, there are 510 characters maximum allowed
for the command and its parameters.

section 2.2.1 note (2):

<hostname> has a maximum length of 63 characters.

But in my case it got cut more on the reception from the server - as the command to send the text is shorter than the notification command from the server. So we have to predict the limit on the receiving side, not just to limit our sending of lines <=510.

The message text should be <=405 if <user> is limited to <=9 but I did not find any limit for the <user> field.

comment:8 Changed 7 years ago by QuLogic

Ticket #9199 has been marked as a duplicate of this ticket.

comment:9 Changed 6 years ago by elb

Ticket #12069 has been marked as a duplicate of this ticket.

comment:10 Changed 3 years ago by kurthrad

  • Cc Julian Mehnle added; Julian Mehnle removed


Is this still an issue to be solved? If yes, I would be happy to at least try to do this.

Last edited 3 years ago by kurthrad (previous) (diff)

comment:11 Changed 3 years ago by pcworld

Yes, this is still an issue in 2.10.7.

comment:12 Changed 2 years ago by belmyst

A way to deal with this would be to check the packet length (irc_send_len on irc.c) prior to sending it (since otherwise you'd have to predict the final length on every part which constructs and send messages). If it's > 512 bytes, don't send it and error out.

Another way could be by verifying the message's resulting length on irc_format (parse.c). The above check could be placed right prior to returning the message string.

The attached fix uses the first approach, using cc86f44f12d0 as a guidance.

Changed 2 years ago by belmyst

Proposed patch, check packet length before sending

comment:13 Changed 2 years ago by Robby

  • Milestone changed from Patches welcome to Patches Needing Review

comment:14 Changed 2 years ago by renatosilva

Maybe this helps?

How long can IRC messages be?

I used this together with Character Counting plugin for calculating an average length limit, but yes the protocol/server/client should not silently truncate it.

Last edited 2 years ago by renatosilva (previous) (diff)

comment:15 Changed 2 years ago by belmyst

Tyvm renatosilva.

elb raised on IRC something similar. In my patch, the message size was checked without taking into account the server overhead: ":" + nick + "!" + user + "@" + host + " " + buf + " :" + CR LF (buf being the char * being sent) However, since the server may set nick, user and host to something different to the values Pidgin has saved, we should take the worst case (everything max length) and reject anything that would overflow it.

I've attached another version. Please review it.

Changed 2 years ago by belmyst

Also count server overhead in the check)

comment:16 Changed 2 years ago by renatosilva

Anyone testing this patch?

Last edited 16 months ago by renatosilva (previous) (diff)

comment:17 Changed 2 years ago by andersaamodt

This is still an issue in 2.10.9... very frustrating and confusing for others. In other clients I've seen long messages automatically broken up. Or, the textbox could just have a maximum length.

comment:18 Changed 20 months ago by bjoernv

I tested the patch in main branch. Messages with more than ~ 500 characters will not be send. But the user does not see any error code, if the message is not send. The user sees a message in debug log.

comment:19 Changed 4 weeks ago by akostadinov

Wow, this is a serious issue. One may think important information has been handed out while it might not have been the case. Never guessed such bug can exist. And reported 8 years ago. Really renders client unusable. Tuning one enthusiast user into non-user.Dunno why I'm whining. Probably I still wish good for the project.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!