[issue36489] add filename_extension_map and/or content-types_map dict(s) to mimetypes
Daniel Black added the comment: Thanks Karthikeyan. That is a bit cumbersome but gets it done. Any value seen in adding as proposed? -- ___ Python tracker <https://bugs.python.org/issue36489> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36489] add filename_extension_map and/or content-types_map dict(s) to mimetypes
New submission from Daniel Black : In https://bugs.python.org/issue36460 (which should be probably be disregarded until AMP is in RFC) I discovered that the types_map dictionary within the mimetypes module is a key: str to key: str (1:1) relationship. The reality is that many filename extensions commonly support multiple content-types and even sub types. A more useful structure might look like: (fne is "file name extension" aka foo) { '.fne': ['type1/subtype', 'type2/subtype'], '.htm': ['text/html', 'text/css', 'text/javascript'], '.html': ['text/html', 'text/css', 'text/javascript'] } However this seems to compete with the functionality of the types map so another consideration is content-types_map where the content-type is the key and the pair values are lists of valid filename extensions: { 'audio/x-aiff': ['.aifc', '.aiff', '.au'], 'text/html': ['.html', '.htm'] } -- messages: 339221 nosy: Daniel Black priority: normal severity: normal status: open title: add filename_extension_map and/or content-types_map dict(s) to mimetypes ___ Python tracker <https://bugs.python.org/issue36489> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36460] Add AMP MIME type support
Daniel Black added the comment: That's exactly what I meant: use, but in a way that cares how that data is structured. Thanks for the pointer, I'll take a look. -- ___ Python tracker <https://bugs.python.org/issue36460> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36460] Add AMP MIME type support
Daniel Black added the comment: I see! Okay... I'll consider a solution to the filetype portion of the mimetypes map. Do you happen to know which other modules may depend on that structure? Yes... the lightning is silly. Dan Black http://dan.black 917-873-3970 On Thu, Mar 28, 2019 at 10:55 AM R. David Murray wrote: > > R. David Murray added the comment: > > That link should do for our purposes here. > > The fact that it is an 'x-' mimetype means it has not been approved at > any level. There might be an in progress application to the mimetype > registry, but if so the web site doesn't mention it anywhere obvious. > > I'm not sure about the filetype problem, but I'm guessing amp isn't the > only mimetype that will have this issue going forward, so we probably need > to come up with a solution. You don't need support from the mimetypes > module to create or manipulate emails using the content-type, though, > so it isn't a blocker on that side. > > That lightning thing is *seriously* hokey :( > > -- > > ___ > Python tracker > <https://bugs.python.org/issue36460> > ___ > -- ___ Python tracker <https://bugs.python.org/issue36460> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36460] Add AMP MIME type support
Daniel Black added the comment: I'm not sure there's an RFC. I searched ietf but found none related to AMP in MIME and AMP along search results were many (not accurate). I actually doubt there's an RFC specific to AMP. What I meant is that AMP is itself RFC compliant with RFC 2045-2050. As for official documentation here is the link to the AMP project's description which gives some context: https://amp.dev/documentation/guides-and-tutorials/integrate/add-email.html?format=email Let me know if you need more information. Dan Black http://dan.black 917-873-3970 On Thu, Mar 28, 2019 at 8:41 AM R. David Murray wrote: > > R. David Murray added the comment: > > Can you provide some links to relevant RFCs or other official documents? > > -- > > ___ > Python tracker > <https://bugs.python.org/issue36460> > ___ > -- ___ Python tracker <https://bugs.python.org/issue36460> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21207] urandom persistent fd - not re-openned after fd close
Daniel Black added the comment: fine by me. was just a thought -- ___ Python tracker <http://bugs.python.org/issue21207> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21207] urandom persistent fd - not re-openned after fd close
Daniel Black added the comment: maybe you've thought and dismissed this already but os.close could call dev_urandom_close for the urandom_fd. Then there's no fstat calls in every random access. As a sweeping close all isn't going to occur that often and extra open probably isn't that much overhead. -- ___ Python tracker <http://bugs.python.org/issue21207> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21207] urandom persistent fd - not re-openned after fd close
Changes by Daniel Black : -- nosy: +grooverdan ___ Python tracker <http://bugs.python.org/issue21207> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8109] Server-side support for TLS Server Name Indication extension
Daniel Black added the comment: nice patch. Thanks for finding the bug. I like the solution with test case. Just needs a small enhancement of documention to ensure other users expect this behaviour. -- ___ Python tracker <http://bugs.python.org/issue8109> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17510] assertEquals deprecated in test_program.py (unittest)
New submission from Daniel Black: Following #9424 here's a patch that changes assertEquals -> assertEqual for Lib/unittest/test/test_program.py against hg tip as of now -- components: Tests files: unittest.patch keywords: patch messages: 184906 nosy: grooverdan priority: normal severity: normal status: open title: assertEquals deprecated in test_program.py (unittest) type: enhancement versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file29533/unittest.patch ___ Python tracker <http://bugs.python.org/issue17510> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10852] SSL/TLS sni use in smtp, pop, imap, nntp, ftp client libs by default
Daniel Black added the comment: Ack. Have fix. Simple if self.certfile or self.keyfile: test added before load_cert_chain. part way through developing test. Thinking #17181 would help. -- ___ Python tracker <http://bugs.python.org/issue10852> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17181] SSLContext.set_servername_callback should be able to set argument
New submission from Daniel Black: I think my original implementation of the SNI callback to see a original sslcontext was wrong. It would be much more useful for the SSLContext.set_servername_callback to take a callable and an object as an argument. This would allow constructs like the following where self can be used within the callback. Example: def cb_sni(ssl_sock, server_name, self): self.sniname = server_name self.context.set_servername_callback(cb_sni, self) The original functionality can still occur with: self.context.set_servername_callback(cb_sni, self.context) Agree? -- components: Library (Lib) messages: 181889 nosy: grooverdan, pitrou priority: normal severity: normal status: open title: SSLContext.set_servername_callback should be able to set argument type: enhancement versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue17181> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17107] test_sni in test_urllib2net could be enabled
Daniel Black added the comment: ask and you shall receive :-) -- keywords: +patch nosy: +grooverdan versions: +Python 3.5 Added file: http://bugs.python.org/file28948/https_sni_test.patch ___ Python tracker <http://bugs.python.org/issue17107> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10852] SSL/TLS sni use in smtp, pop, imap, nntp, ftp client libs by default
Daniel Black added the comment: I thought previous comments you wanted SSLContext to become the primary api rather than wrap_socket? Coding this into the examples is probably a good way of making this happen. -- ___ Python tracker <http://bugs.python.org/issue10852> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10852] SSL/TLS sni use in smtp, pop, imap, nntp, ftp client libs by default
Daniel Black added the comment: ok. should library/ssl.rst be updated to use a SSLContext example? -- ___ Python tracker <http://bugs.python.org/issue10852> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10851] further extend ssl SNI and ciphers API
Daniel Black added the comment: acknowledged. Makes sense. -- resolution: -> rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue10851> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10852] SSL/TLS sni use in smtp, pop, imap, nntp, ftp client libs by default
Daniel Black added the comment: dup #10853 -- nosy: -pitrou resolution: -> duplicate status: open -> closed ___ Python tracker <http://bugs.python.org/issue10852> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10853] SSL/TLS sni use in smtp, pop, imap, nntp, ftp client libs by default
New submission from Daniel Black : Like r85793, sni is enabled by default for url and https classes. This continues the consistency throughout the python libraries by adding it to other places where wrap_socket is used to instigate a SSL/TLS connection. -- components: Library (Lib) files: sni-pop-smtp-imap-nntp.patch keywords: patch messages: 125622 nosy: grooverdan, pitrou priority: normal severity: normal status: open title: SSL/TLS sni use in smtp,pop,imap,nntp,ftp client libs by default type: feature request versions: Python 3.3 Added file: http://bugs.python.org/file20300/sni-pop-smtp-imap-nntp.patch ___ Python tracker <http://bugs.python.org/issue10853> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10852] SSL/TLS sni use in smtp, pop, imap, nntp, ftp client libs by default
New submission from Daniel Black : Like r85793, sni is enabled by default for url and https classes. This continues the consistency throughout the python libraries by adding it to other places where wrap_socket is used to instigate a SSL/TLS connection. -- components: Library (Lib) files: sni-pop-smtp-imap-nntp.patch keywords: patch messages: 125621 nosy: grooverdan, pitrou priority: normal severity: normal status: open title: SSL/TLS sni use in smtp,pop,imap,nntp,ftp client libs by default type: feature request versions: Python 3.3 Added file: http://bugs.python.org/file20299/sni-pop-smtp-imap-nntp.patch ___ Python tracker <http://bugs.python.org/issue10852> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8109] Support for TLS Server Name Indication extension
Daniel Black added the comment: issue #5639 only has functionality for client side SNI. Server side SNI is still missing. For server side SNI to be supported a server program should be able to retrieve the server name provided by the client call and alter the server certificate/key before the server completes the TLS/SSL connection. -- nosy: +grooverdan ___ Python tracker <http://bugs.python.org/issue8109> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10851] further extend ssl SNI and ciphers API
New submission from Daniel Black : as a further extension to issue #5639 (sni) and issue #8322 this patch provides the ability to set ciphers in the SSLContext.wrap_socket and server_hostname in ssl.wrap_socket. This just makes all the ssl apis look the same. Restructured the documentation associated with these functions to all be around the wrap_socket method. -- components: Library (Lib) files: p3k-sni-ciphers.patch keywords: patch messages: 125612 nosy: grooverdan, pitrou priority: normal severity: normal status: open title: further extend ssl SNI and ciphers API versions: Python 3.3 Added file: http://bugs.python.org/file20296/p3k-sni-ciphers.patch ___ Python tracker <http://bugs.python.org/issue10851> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2973] _ssl compiler warnings
Daniel Black added the comment: out of date? still occurs on: AMD64 Leopard 2.7: http://www.python.org/dev/buildbot/all/builders/AMD64 Leopard 2.7/builds/308/steps/compile/logs/warnings (57) PPC Leopard 2.7: http://www.python.org/dev/buildbot/all/builders/PPC Leopard 2.7/builds/532/steps/compile/logs/warnings (20) PPC Tiger 2.7: http://www.python.org/dev/buildbot/all/builders/PPC Tiger 2.7/builds/532/steps/compile/logs/warnings (25) PPC Leopard 3.1: http://www.python.org/dev/buildbot/all/builders/PPC Leopard 3.1/builds/674/steps/compile/logs/warnings (20) x86 gentoo 3.1 : http://www.python.org/dev/buildbot/all/builders/x86 gentoo 3.1/builds/1412/steps/compile/logs/warnings (8) x86 FreeBSD 3.1: http://www.python.org/dev/buildbot/all/builders/x86 FreeBSD 3.1/builds/719/steps/compile/logs/warnings (7) 3.1.dmg: http://www.python.org/dev/buildbot/all/builders/3.1.dmg/builds/339/steps/compile/logs/warnings (20) btw I don't think the gentoo ones are accurate - old versions of openssl have been gone for a while: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/openssl/openssl-0.9.7m.ebuild?hideattic=0&view=log -- ___ Python tracker <http://bugs.python.org/issue2973> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5639] Support TLS SNI extension in ssl module
Daniel Black added the comment: > msg106323 - Author: Antoine Pitrou (pitrou) Date: 2010-05-22 20:17 I quite like your proposed alternative here. Not sure when/if I'll get to implement this. > msg106324 - Author: Jean-Paul Calderone (exarkun) Date: 2010-05-22 22:17 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. -- ___ Python tracker <http://bugs.python.org/issue5639> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5639] Support TLS SNI extension in ssl module
Daniel Black added the comment: Hey Phil, > (Sorry for dropping this, lost available time) know the feeling :-( > use of SNI needs to be something that can be disabled maybe. See small rational below: > and people need to be able to connect to host A while supplying host B This seems to be a fringe case for usage and I seem to thing adding this would overly complicate the API. When testing hosts you would have all the names in DNS I'd assume. > Unless s.connect() gains a keep_original_hostname=False option (?), this is hard to do. Is this starting to look too complicated? Options for client side SNI: 1. wrapssl() - defaults to SNI enabled on SSL2/TLS1 connections (compile time/module level/object variable disable if really needed?) 2. wrapssl(server_hostname=True/False) - enable SNI using the connect hostname (if domainname and not IP/socket) 3. wrapssl(server_hostname=True/False/String) - True - enable SNI as above, False/None- don't use SNI or use hostname if a String. 4. wrapssl(server-hostname=String) 5. connect() should an override_server_hostname=False more? > Then there's the principle of least surprise -- while it would be nice to get SNI working automatically for everyone, it's still plausible that amongst the various TLS servers out there are some which break horribly for SNI and upgrading Python shouldn't break the tools in use. Small rational to enable SNI by default: 1. SNI probably won't break too much stuff. It was only in July 2009 that Apache-2.2.12 got officially released with proper SNI support. Patches existed before then however deployment was limited. mod_gnutls did implemented this earlier however I never thought this was widely used. Vista IE7 got SNI support in ~2005 (http://blogs.msdn.com/ie/archive/2005/10/22/483795.aspx) FF got SNI support in the 2.0 release (October 24, 2006, wikipedia) (https://bugzilla.mozilla.org/show_bug.cgi?id=116169#c26) The OpenSSL server side API for SNI required the registration of a callback to receive the SNI name. It is possible that there are some faulty implementations in this part of the server code. The default case that a TLS server doesn't account for SNI is very safe as it won't ever get a callback for it. The existence of wide spread client side support with limited server support hasn't broken the web. > So I tend towards favouring "make use of the newer, less well tested, protocol feature something that has to be explicitly enabled", even if it adds a line to boilerplate -- if SNI ever takes over the world (as Host: headers in HTTP have) then it can be defaulted on in future perhaps? 2. I think with p3k there is an opportunity to put something in that may break stuff. The release noted didn't guarantee stuff would work compatibly. 3. supporting SNI clients by default may actually break less stuff that not supporting SNI client. e.g. Webhosting companies may embrace the SNI features of Apache for maximum IP utilization breaking the non-SNI aware clients (which won't be the majority of web browsers). > With checking for an IP address? To be RFC compliant IP addresses shouldn't be used in SNI. Apart from socket family checking (AF_INET/AF_INET6) and doing a regex on the name I couldn't see an easy way to do this even looking at the low level socketmodule.c file. Maybe I need to look deeper. I could cheat and look at the Firefox crypto (NSS) code though. just my current thoughts -- ___ Python tracker <http://bugs.python.org/issue5639> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5885] uuid.uuid1() is too slow
Daniel Black added the comment: to prove it a bit more - ctype benchmark >>> import ctypes, ctypes.util >>> def uu1(n): ... t = time.time() ... _buffer = ctypes.create_string_buffer(16) ... for x in range(n): ... uuid._uuid_generate_time(_buffer) ... print('%.3f microseconds' % ((time.time() - t) * 100.0 / n)) ... >>> uu1(100) 15.819 microseconds -- ___ Python tracker <http://bugs.python.org/issue5885> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5885] uuid.uuid1() is too slow
Daniel Black added the comment: This is a slightly crude module version. The speedups were only 10% Python 3.2a0 (py3k:74612M, Sep 1 2009, 18:11:58) [GCC 4.3.2] on linux2 Using the same test from Wang Chun: before: uuid1(100) 101.759 microseconds after: uuid1(100) 91.663 microseconds The delays are clearly in the _byte array copying as indicated by the test below: >>> import sys, time, uuid >>> def uu(n): ... t = time.time() ... for x in range(n): ... uuid._uuid_generate_time_fast() ... print('%.3f microseconds' % ((time.time() - t) * 100.0 / n)) ... [72265 refs] >>> uu(100) 13.157 microseconds [72267 refs] I would expect fixing this for the ctypes version would have a similar speedup. -- keywords: +patch nosy: +grooverdan Added file: http://bugs.python.org/file14814/uuid_c_module.patch ___ Python tracker <http://bugs.python.org/issue5885> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6814] xrange removal from documentation
New submission from Daniel Black : xrange still exists in bits of documentation here and there. patch fixes it. -- assignee: georg.brandl components: Documentation files: xrange-doco.patch keywords: patch messages: 92120 nosy: georg.brandl, grooverdan severity: normal status: open title: xrange removal from documentation versions: Python 3.0, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file14813/xrange-doco.patch ___ Python tracker <http://bugs.python.org/issue6814> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6813] update format() documentation and tutorial
New submission from Daniel Black : Release notes show the use of '{}'.format('this') and the attached patch updates this to be the default example in the tutorial. Library references are updated to show field_name as optional and a few examples are added. Relates to the improvements from issue 5237. -- assignee: georg.brandl components: Documentation files: documentation-str-format.patch keywords: patch messages: 92119 nosy: georg.brandl, grooverdan severity: normal status: open title: update format() documentation and tutorial versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file14812/documentation-str-format.patch ___ Python tracker <http://bugs.python.org/issue6813> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3212] ssl module - should test for a wrong cert
Daniel Black added the comment: Is fixed in p3k Mon Sep 8 16:45:19 2008 UTC http://svn.python.org/view/python/branches/py3k/Lib/test/test_ssl.py?r1=65837&r2=66311 -- nosy: +grooverdan versions: +Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue3212> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2973] _ssl compiler warnings
Daniel Black added the comment: The changeset that changed the definitions is here: http://cvs.openssl.org/chngview?cn=12024 (2004-Mar-14 23:15:13 (UTC)) As you can see there is no easy identifier in the changeset (i'm not sure how portable an ifdef on a typedef is (possible asn1_const_ctx_st/ASN1_const_CTX)). The patch i've done goes of then next OPENSSL_VERSION_NUMBER change which occurred here http://cvs.openssl.org/filediff?f=openssl/crypto/opensslv.h&v1=1.36.2.35&v2=1.36.2.36 (2004/03/17 11:40:44) ~3 days later. Same patch applies to p3k -- keywords: +patch nosy: +grooverdan versions: +Python 2.7, Python 3.0, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file14811/issue2973-D2I_PARAMETER_2_TYPE.patch ___ Python tracker <http://bugs.python.org/issue2973> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5639] Support TLS SNI extension in ssl module
Daniel Black added the comment: The small deficiency with these patches is that the specified server_hostname is almost always the hostname that is used in the socket pair of connect. Is it appropriate to grab the hostname value and use it in the SNI extension header? -- ___ Python tracker <http://bugs.python.org/issue5639> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5639] Support TLS SNI extension in ssl module
Daniel Black added the comment: current self tests cannot fully test the existence of the SNI extension as there is no server side support. This client script run with argument sni.velox.ch will show the "Great! Your client its ClientHello: sni.velox.ch" on the output. -- nosy: +janssen type: -> feature request Added file: http://bugs.python.org/file14810/pytest.py ___ Python tracker <http://bugs.python.org/issue5639> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5639] Support TLS SNI extension in ssl module
Changes by Daniel Black : -- versions: +Python 2.7, Python 3.2 -Python 2.6 ___ Python tracker <http://bugs.python.org/issue5639> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5639] Support TLS SNI extension in ssl module
Daniel Black added the comment: py3k version -- Added file: http://bugs.python.org/file14809/python-3K-74602-ssl_client_sni.path ___ Python tracker <http://bugs.python.org/issue5639> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5639] Support TLS SNI extension in ssl module
Daniel Black added the comment: patch against TRUNK (2.7) with self tests and doco. Essentially the same code as pdp with a SSLv2 check before using the SNI extension. Contains some spacing cleanups that where highlighted by vim. -- nosy: +grooverdan Added file: http://bugs.python.org/file14808/python-HEAD-74602-ssl_client_sni.path ___ Python tracker <http://bugs.python.org/issue5639> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com