This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: telnetlib option subnegotiation fix
Type: Stage:
Components: Library (Lib) Versions: Python 2.3
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: georg.brandl, sonderblade, sreeves
Priority: normal Keywords: patch

Created on 2003-01-07 21:51 by sreeves, last changed 2022-04-10 16:06 by admin. This issue is now closed.

File name Uploaded Description Edit
telnetlib-patch.diff sreeves, 2003-01-07 21:57 telnet subnegotiation patch
Messages (4)
msg42360 - (view) Author: Steve Reeves (sreeves) Date: 2003-01-07 21:51
The telnetlib patch #630829 (committed as v1.20) for
option subnegotiation doesn't work as-is.  There are
several problems.

1) The option negotiation callback should be a method
of the Telnet class, not a separate function.  The
callback is supposed to call the read_sb_data method
when it receives SB or SE, but of which object?

I think the callback should have been a method all
along.  It should be able to change the object's state
based on the negotiation.  Generally when implementing
a new protocol extension, you'll subclass Telnet, add
the new behavior, and then have the callback set a flag
in the object to activate the new behavior after it has
been negotiated.

The default DONT/WONT behavior can be moved out of the
depths of process_rawq() into the callback method. 
Subclasses can then just forward to the parent class
when they get an option they don't care about, instead
of having to reimplement the default behavior.

If the callback is a method, the socket argument is
still available as self.sock.  The
set_option_negotiation_callback method and the checks
for "if self.option_callback:" would not be needed.

Changing the callback to a method will break
compatibility with Python 2.2, however.

2) On receipt of SB and SE, the callback is always
called with NOOPT.  The option is never passed.  (It
actually gets stored as the first part of the parameter
data and returned by read_sb_data().)

3) The callback is called on the receipt of both SB
_and_ SE.  The SB call is completely superfluous.  The
option and parameter data have not been read yet, so
there is nothing for the callback to do.

The attached patch fixes these and adds support for the
NOP command.  It also includes documentation changes
and an example of implementing some options.

Some other thoughts:

The name "option_callback" is a little misleading.  The
callback is executed in response to all telnet protocol
commands, not just the ones dealing with options.

Why define and pass NOOPT for the case when there is no
option rather than use None?

The only place the SB parameter data will (can safely?)
be used is in the callback.  Why not pass it as another
optional parameter and skip the need for read_sb_data()?

A potential name conflict: the EOR telnet option
defines a new command code also called EOR (with a much
different numeric value).  The C header file
<arpa/telnet.h> prefixes all the options with TELOPT_,
so there is no conflict there, but telnetlib drops the
msg42361 - (view) Author: Steve Reeves (sreeves) Date: 2003-01-07 21:57
Logged In: YES 

Sorry, the patch wasn't uploaded for some reason.  Trying again.
msg42362 - (view) Author: Björn Lindqvist (sonderblade) Date: 2007-03-09 00:16
This patch is very similar to #1520081. They both suggest replacing set_option_negotiation_callback with a method on the Telnet object which I think makes perfect sense. They both contain big and useful updates to the documentation. This patch also contain a useful refactoring of the process_rawq() method. I think a merged patch of them both should be applied. But IMHO, it should wait to Py3k because then API can be broken and then set_option_negotiation_callback can be eliminated. 
msg42363 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2007-03-17 21:45
Superseded by #1678077.
Date User Action Args
2022-04-10 16:06:07adminsetgithub: 37736
2003-01-07 21:51:41sreevescreate