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.

Author exarkun
Recipients exarkun, giampaolo.rodola, grooverdan, janssen, jcea, pdp, pitrou
Date 2010-05-23.16:37:47
SpamBayes Score 3.4445606e-05
Marked as misclassified No
Message-id <1274632670.7.0.78064780398.issue5639@psf.upfronthosting.co.za>
In-reply-to
Content
> Sorry I don't like this as much. I believe following the RFC for TLS SNI should be implicit and not something the programmer need to put effort into achieving. I acknowledge this approach does go against some explicit behaviour programming quality metrics.

It's almost always wrong for Python to enforce a particular *policy*, particularly in a very low level API (which is what the ssl module should be).  Python's main job is to make it *possible* to do things.  It's the application developer's job to decide what things should be done.

It would be entirely appropriate, though, for a higher-level interface (for example, the httplib module) to take care of this itself and not require users to explicitly specify things separately.

> Well, the hostname should be specific to a connection, so I'm not sure it makes sense to set it on the context.

That doesn't make sense to me.  For example, consider the case where you're talking to a web service.  The hostname lookup might result in 10 A records, which you then drop into a connection pool.  Your application doesn't care which server you talk to (and maybe it talks to serveral, or all, of them).  But it does want to specify the same hostname for each.

> (besides, the OpenSSL APIs only allow it to be set on the SSL structure)

Nope, I checked before making the suggestion.  There's an SSL_CTX_ version of this API (in addition to the SSL_ version).
History
Date User Action Args
2010-05-23 16:37:50exarkunsetrecipients: + exarkun, jcea, janssen, pitrou, giampaolo.rodola, pdp, grooverdan
2010-05-23 16:37:50exarkunsetmessageid: <1274632670.7.0.78064780398.issue5639@psf.upfronthosting.co.za>
2010-05-23 16:37:49exarkunlinkissue5639 messages
2010-05-23 16:37:48exarkuncreate