View Ticket
Ticket UUID: f798e2ea1299e4fe603c8bdbfbfea3c2e7beb4d9
Title: TclTLS does not retain socket state when importing
Status: Open Type: Code Defect
Severity: Severe Priority: Immediate
Subsystem: Resolution: Open
Last Modified: 2017-12-21 10:02:35
Version Found In: 1.7.14
User Comments:
anonymous added on 2017-12-20 22:15:19:
11:42 <@ijchain> <rmax_> rkeene: [tls::import] appears to switch a socket that was in -blocking 0 mode before to -blocking 1.
11:44 <@ijchain> <rmax_> ... it also sets -translation to {lf lf}
11:45 <@ijchain> <rmax_> Haven't compared it with the old version yet, but -blocking 1 would explain the behaviour I am seeing.
11:47 <@ijchain> <rmax_> it also enforces -encoding binary
11:52 <@ijchain> <rmax_> Indeed, if I hack [fconfigure $sock -blocking 0 -buffering none -encoding utf-8] (copied from tkchat) into jabberlib immediately after tls::import/tls::handshake, the hang is gone.
11:53 <@ijchain> <rmax_> rkeene: I think this is a regression from the old tls package.
11:54 <@ijchain> <rmax_> [tls::import] should probably not change any [chan configure] options.
11:56 <@ijchain> <rmax_> OK, so old tls already changed -translation to lf.
11:57 <@ijchain> <rmax_> But it does retain blocking state and encoding.

anonymous added on 2017-12-21 10:02:35:
This is rmax. :)

I wonder why putting the to be imported socket in blocking mode was added at first place, but unfortunately the checkin comment doesn't tell it:

Could it be that you added this for debugging reasons and forgot to remove it before committing?

BTW, the proposed fix only preserves the state of -translation, but -encoding and -eofchar need to be preserved as well, because setting "-translation binary" implicitly also changes these two options.