ZNC having issues with too long of a message about irc-slack HOT 15 CLOSED

Thanks. I also assume that the safe way to split is by spaces. I see a few edge cases:

Yes. That would be a standard way of dealing with it.

• what if a string is too long (e.g. nick very long nick). Return an error? Truncate silently? Drop the message?

I'm not sure what limits slack has for this. But truncating silently might be a good idea because these messages are really only meant to be sent when joining or leaving a channel. IIRC.

• what if there are multiple contiguous spaces as separator? I guess it's safe to split normally and ignore that

If you could split on a "\w" that would be best, but I know performance hits can occur when using regex.

from irc-slack.

Thanks for reporting the bug! I will test on a large Slack team and let you know. Unfortunately I will be on business trip for the next two week, so apologies in advance for the high latency in responding here.

Sorry for the multiple bugs today.

Oh no, please keep reporting all the bugs you find!
My use case is pretty limited (a few small teams and irssi) but the more use cases we cover, the better :)

from irc-slack.

I know this is a somewhat fundamental change to the application, but do you need any help with testing a fix for this? This is literally the last hurdle I have to deal so I can stop using the web interface.

from irc-slack.

hey @Syloq , I don't think this is going to be hard to fix. I've come back from business trips two days ago, so I can have a look at it this week

from irc-slack.

@Syloq , do you have an example of how chunking should happen?

from irc-slack.

As per RFC2812,

   IRC messages are always lines of characters terminated with a CR-LF
   (Carriage Return - Line Feed) pair, and these messages SHALL NOT
   exceed 512 characters in length, counting all characters including
   the trailing CR-LF. Thus, there are 510 characters maximum allowed
   for the command and its parameters.  There is no provision for
   continuation of message lines.  See section 6 for more details about
   current implementations.

from irc-slack.

@insomniacslk RFC2812 would be a standard way of handling these. ZNC and most other IRCd's handle it with different limits. Most clients, from my understanding, will handle the multiple messages individually as they come in. So you could send the same numeric each time with different data. The clients should be able to handle that just fine.

from irc-slack.

So you could send the same numeric each time with different data

That's what I assumed at first, but I imagine there are commands that cannot be invariantly be broken into multiple lines

from irc-slack.

That's what I assumed at first, but I imagine there are commands that cannot be invariantly be broken into multiple lines

That's possibly very true, however, I'd imagine those numerics are only when connecting to the server itself. I don't have specifics on that behavior. I do believe is that there are a few numerics that are typically very long, like the 353 I mentioned initially, are done in such a way that clients will be able to handle the massive amount of messages.

from irc-slack.

I am thinking of something like "TOPIC", where someone sets a long topic whose numeric (332) exceeds the 512 bytes. If we blindly split, you would get two TOPIC lines, and the client believes that the topic has been changed more than once, and will take only the last chunk. Am I missing something?

from irc-slack.

If we can come up with a whitelist of numerics that can be split, I'd rather do that as a stop-gap. I guess we can start with the ones you faced, and add per need

from irc-slack.

That's a good point. It sounds like you'd have to enumerate which numerics are eligible for chunking. Not a great way of handling that for sure. And then in that light, you'd have to truncate some that are longer than the 510 characters.

from irc-slack.

I'll start with 353 for now, let me know if you find more candidates for chunking

from irc-slack.

If we can come up with a whitelist of numerics that can be split, I'd rather do that as a stop-gap. I guess we can start with the ones you faced, and add per need

I think 353 and 352 will be the best candidates. The first is a /names reply the other is a /who reply.

from irc-slack.

Thanks. I also assume that the safe way to split is by spaces. I see a few edge cases:

• what if a string is too long (e.g. nick very long nick). Return an error? Truncate silently? Drop the message?
• what if there are multiple contiguous spaces as separator? I guess it's safe to split normally and ignore that

from irc-slack.