search

shizmob / pydle

An IRCv3-compliant Python 3 IRC library.
BSD 3-Clause "New" or "Revised" License
154 stars 48 forks source link

CTCP not according to specifcation? #69

Open Querela opened 6 years ago

Querela commented 6 years ago

https://github.com/Shizmob/pydle/blob/60ede96669d77e86b8ee264ebc21ab669418fb7b/pydle/features/ctcp.py#L102

I think, there may be cases where CTCP is not correctly recognized. More specifically, if the CTCP message follows a normal text message (or is embedded in it).

see example 3 in http://www.irchelp.org/protocol/ctcpspec.html

The text part of a PRIVMSG or NOTICE might contain zero or more extended messages, intermixed with zero or more chunks of non-extended data. https://github.com/irchelp/wio/blame/gh-pages/protocol/ctcpspec.md#L189

Furthermore, it should be possible to send multiple CTCP messages (chained together). A check for CTCP should therefore (1) check for CTCP_DELIMITER and if found (2) check/extract all CTCP messages. (3) handle CTCP messages/handle remaining text messages (if available)

I'm not sure how CTCP (aside from DCC) occurs in the wild but the current approach may not work for all cases.

rakiru commented 6 years ago

Basically no client implements the original CTCP spec. The only real potential case where it doesn't catch current usage is where message splitting results in the last character not being the delimiter any more.

A draft of an updated spec that details what is commonly implemented today: https://tools.ietf.org/html/draft-oakley-irc-ctcp-02

shizmob commented 6 years ago

This seems important to double-check, thanks! I'll see if there's any cases out there that aren't caught by current pydle.