Message 252635 - Python tracker

➜

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.

In-reply-to
Author	Alex Warhawk
Recipients	Alex Warhawk, Mark.Ribau, Ye.Wang, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou
Date	2015年10月09日.18:51:57
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<1444416717.83.0.336183556581.issue19500@psf.upfronthosting.co.za>

Content
Even after enabling client cache one still has to call SSL_set_session. See documentation of SSL_CTX_set_session_cache_mode point SSL_SESS_CACHE_CLIENT. I started thinking about not exposing a SSL_SESSION object to the user but rather extending wrap_socket to take an already established socket as argument and use that socket's session object. This way I can ensure that both sockets share the same SSL context I am not really convinced by this idea myself, what do you think about this? Any better ideas?

Content

Even after enabling client cache one still has to call SSL_set_session. See documentation of SSL_CTX_set_session_cache_mode point SSL_SESS_CACHE_CLIENT.
I started thinking about not exposing a SSL_SESSION object to the user but rather extending wrap_socket to take an already established socket as argument and use that socket's session object. This way I can ensure that both sockets share the same SSL context
I am not really convinced by this idea myself, what do you think about this? Any better ideas?

History
Date	User	Action	Args
2015年10月09日 18:51:57	Alex Warhawk	set	recipients: + Alex Warhawk, janssen, pitrou, giampaolo.rodola, christian.heimes, dstufft, Ye.Wang, Mark.Ribau
2015年10月09日 18:51:57	Alex Warhawk	set	messageid: <1444416717.83.0.336183556581.issue19500@psf.upfronthosting.co.za>
2015年10月09日 18:51:57	Alex Warhawk	link	issue19500 messages
2015年10月09日 18:51:57	Alex Warhawk	create

homepage