Bug 136545 - xchat's IRC driver does not handle multiline messages gracefully
xchat's IRC driver does not handle multiline messages gracefully
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: xchat (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Reed
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-20 16:51 EDT by Daniel Reed
Modified: 2008-07-24 11:12 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-20 18:23:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
low-level CTCP dequoter, new CTCP parser, inline CTCP dequoter (4.69 KB, patch)
2004-10-21 23:58 EDT, Daniel Reed
no flags Details | Diff
Updated version of zed's version of daniel reed's patch (6.77 KB, patch)
2008-07-24 11:12 EDT, Uli M
no flags Details | Diff

  None (edit)
Description Daniel Reed 2004-10-20 16:51:13 EDT
*** This bug has been split off bug 136542 ***

xchat's IRC driver does not handle multiline messages gracefully.

Reproducible: Always
Steps to Reproduce:
1. Join a xchat IRC client to #test
2. Join a naim IRC client to #test
3. Paste more than one line of text into the naim client and witness the xchat
client

Actual Results:  
xchat renders the multiline delimiter literally, as *r*n where * is a special
graphic denoting the hexadecimal value of the CTCP escape character (x0010):

<n> This is a first line*r*nThis is a second line.
<n> This is a second message.

Expected Results:  
xchat should render the embedded newline in a pleasing way, such as:
<n> This is a first line
    This is a second line.
<n> This is a second message.

[http://www.irchelp.org/irchelp/rfc/ctcpspec.html]

*****************
LOW LEVEL QUOTING
*****************

Even though messages to and from IRC servers cannot contain NUL, NL,
or CR, it still might be desirable to send ANY character (in so called
"middle level messages") between clients. In order for this to be
possible, those three characters have to be quoted. Therefore a quote
character is needed. Of course, the quote character itself has to be
quoted too, since it is in-band.

	M-QUOTE	::= '\020'

(Ie a CNTRL/P).

When sending a middle level message, if there is a character in the
set { NUL, NL, CR, M-QUOTE } present in the message, that character is
replaced by a two character sequence according to the following table:

	NUL	--> M-QUOTE '0'
	NL	--> M-QUOTE 'n'
	CR	--> M-QUOTE 'r'
	M-QUOTE	--> M-QUOTE M-QUOTE

When receiving a low level message, if there is a M-QUOTE, look at the
next character, and replace those two according to the following table
to get the corresponding middle level message:

	M-QUOTE '0'	--> NUL
	M-QUOTE 'n'	--> NL
	M-QUOTE 'r'	--> CR
	M-QUOTE M-QUOTE	--> M-QUOTE

If the character following M-QUOTE is not any of the listed
characters, that is an error, so drop the M-QUOTE character from the
message, optionally warning the user about it. For example, a string
'x' M-QUOTE 'y' 'z' from a server dequotes into 'x 'y' 'z'.

 ...

- --- Example 1 -----------------------------------------------------------------

A user (called actor) wanting to send the string:

	Hi there!\nHow are you?

to user victim, i.e. a message where the user has entered an inline
newline (how this is done, if at all, differs from client to client),
will result internaly in the client in the command:

	PRIVMSG victim :Hi there!\nHow are you? \K?

which will be CTCP quoted into:

	PRIVMSG victim :Hi there!\nHow are you? \\K?

which in turn will be low level quoted into:

	PRIVMSG victim :Hi there!\020nHow are you? \\K?

and sent to the server after appending a newline at the end.

This will arrive on victim's side as:

	:actor PRIVMSG victim :Hi there!\020nHow are you? \\K?

(where the \\K would look similar to OK in SIS D47 et. al.) which after
low level dequoting becomes:

	:actor PRIVMSG victim :Hi there!\nHow are you? \\K?

and after CTCP dequoting:

	:actom PRIVMSG victim :Hi there!\nHow are you? \K?

How this is displayed differs from client to client, but it suggested
that a line break should occour between the words "there" and "How".
Comment 2 Daniel Reed 2004-10-21 23:58:54 EDT
Created attachment 105635 [details]
low-level CTCP dequoter, new CTCP parser, inline CTCP dequoter

This seems to work for me. To test the specific functionality, sign on to an
IRC server in xchat, then telnet to the IRC server on port 6667. If you are
signed on as "victim" in xchat, type the following in telnet (after supplying
the USER and NICK commands to sign on):

PRIVMSG victim :line^AVERSION^A 1^Pr^Pnline ^APING 1234^A2

It should show up as a CTCP request VERSION, a CTCP request PING 1234, and a
two-line message:
actor | line 1
      | line 2
Comment 3 Daniel Reed 2005-01-05 16:06:31 EST
This patch is in our builds as of xchat-2.4.1-2.
Comment 4 Uli M 2008-07-24 11:12:15 EDT
Created attachment 312568 [details]
Updated version of zed's version of daniel reed's patch

DCC, CTCP SOUND, and CTCP TIME seem to be working fine.

Note You need to log in before you can comment on or make changes to this bug.