Skip to content
This repository has been archived by the owner on Nov 23, 2017. It is now read-only.

starttls #79

GoogleCodeExporter opened this issue Apr 10, 2015 · 6 comments

starttls #79

GoogleCodeExporter opened this issue Apr 10, 2015 · 6 comments


Copy link

Glyph and Antoine really want a API to upgrade an existing Transport/Protocol 
pair to SSL/TLS, without having to create a new protocol.

Original issue reported on by on 24 Oct 2013 at 11:47

Copy link

What exactly should be done?
Should protocol to be informed about upgrading to TLS? That's requires new 
callback method in protocol contract.

Nikolay Kim and I have alternative proposal: add .detach() method to stream 
transports for destroying transport without closing underlying socket.

There is my thoughts.

The method should return Future.
Proposed behavior is: 
1. call event_loop.remove_reader(fd) and set some internal flag to don't close 
the socket.
2. after sending transport's write buffer (if any) to the socket transport 
removes own writer and sets Future result to None without closing the socket. 
3. If sending write buffer produces error the exception will be passed to both 
._force_close(exc) and future.set_exception(exc) in that order. Socket will be 
4. Otherwise protocol receives .eof_received() notification, socket is not 
closed. Transport calls protocol.detached() method instead to notify for 
detachment. protocol.connection_lost is not called. .detached() method is 
optional, if protocols doesn't implement it the base Protocol class doesn't 
5. After waiting for future (e.g. by `yield from transport.detach()`) client 
code will receive raw socket instance:
   rawsocket = yield from transport.detach()
The client is free to pass the same protocol instance to upcoming 
loop.create_connection() call or make new protocol.
For former client will get .connection_made again.

The benefit of proposal: we also support migration to SSL/TLS for unix sockets, 
pipes etc.

Developer can whatever he wants, even switch back to blocking mode and some 
other staff.

Original comment by on 16 Jun 2014 at 7:36

Copy link

.detach() transport's method should to return the future with rawsocket for 
success or exception if write buffer cannot be sent.

Original comment by on 16 Jun 2014 at 7:51

Copy link

It will become possible to implement STARTTLS when SSL was be rewritten by this 

Original comment by on 8 Jan 2015 at 11:23

Copy link

Discussion about STARTTLS in a thread on the Tulip mailing list, when the PEP 
was written:!msg/python-tulip/kEYYkq-TNnw/ueouVU3CvOMJ

Original comment by on 13 Jan 2015 at 8:49

Copy link

The new SSL implementation has been merged, it can be used on Python 3.5 (and 

Original comment by on 14 Jan 2015 at 12:51

Copy link

There's now a CPython repo issue open for this ( and we have a possible volunteer.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet

No branches or pull requests

2 participants