Right now ngIRCd terminates any connection that sends in a message longer than 512 chars including line termination (see conn.c:1232).
This strikes me as a bit brutal. Other possibilities include: truncating the message, ignoring the message, or replying with some error code.
RFC 2812 doesn't directly specify what should happen when messages exceed the maximum length, but in at least once place it implies they should be truncated. In the description of ISON, it states, "The only limit on the number of nicks that may be checked is that the combined length MUST NOT be too large as to cause the server to chop it off so it fits in 512 characters."
Thoughts?
Dana
Before compiling a new version of ngIRCd I always remove the termination part so the message will just be ignored. I'm all for a general change of the demons behavior towards trunkating the messages.
Kind regards, Jens
2008/2/18, Dana Dahlstrom dana+70@cs.ucsd.edu:
Right now ngIRCd terminates any connection that sends in a message longer than 512 chars including line termination (see conn.c:1232).
This strikes me as a bit brutal. Other possibilities include: truncating the message, ignoring the message, or replying with some error code.
RFC 2812 doesn't directly specify what should happen when messages exceed the maximum length, but in at least once place it implies they should be truncated. In the description of ISON, it states, "The only limit on the number of nicks that may be checked is that the combined length MUST NOT be too large as to cause the server to chop it off so it fits in 512 characters."
Thoughts?
Dana _______________________________________________ ngIRCd-ML mailing list ngIRCd-ML@Arthur.Ath.CX http://arthur.ath.cx/mailman/listinfo/ngircd-ml
Hi!
Am 20.02.2008 um 08:58 schrieb "Jens Kleine" jenskleine@googlemail.com:
Before compiling a new version of ngIRCd I always remove the termination part so the message will just be ignored. I'm all for a general change of the demons behavior towards trunkating the messages.
The problem is that the oversized command can not only contain "dumb text" but parameters of IRC commands. And it is dangerous to cut off these possible parameters because the state of all the servers in the network must be identical.
So the only sane thing a server can do to ensure a valid state is to disconnect the client which violates the protocol.
Regards Alex
On 2008-02-24 at 01:18 +0100, Alexander Barton wrote:
The problem is that the oversized command can not only contain "dumb text" but parameters of IRC commands. And it is dangerous to cut off these possible parameters because the state of all the servers in the network must be identical.
So the only sane thing a server can do to ensure a valid state is to disconnect the client which violates the protocol.
I've tried sending messages > 512 chars to many other IRC servers, and none of them disconnects the client. As RFC 2812 implies, they truncate the message to 512 characters.
How could truncating an incoming message compromise server state?
Dana
-
Alexander Barton -
Dana Dahlstrom -
Jens Kleine