[issue30562] SSL socket does not respect SO_RCVTIME0 timeouts
New submission from Allan Crooks: I initially filed this ticket against the ldap3 library, as this is where I first encountered the issue: https://github.com/cannatag/ldap3/issues/356 I've attached a file which reproduces the issue using the standard library - it makes both a HTTP and HTTPS request to a link that should return a HTTP response after 10 seconds, but we set the socket option SO_RCVTIMEO to 2 seconds. This should result in a read timeout while waiting for a response. On my 64 bit Ubuntu 16.04 machine, the HTTP connection times out as expected, but the HTTPS connection doesn't time out at all (and so ends up reading the HTTP response). It doesn't seem to be an issue specific to HTTPS - I ran into the original issue while using TLS for an LDAP connection using the ldap3 library. If you follow the comments in the ticket, a connection with SO_RCVTIMEO set to 3 seconds ended up taking 1076 seconds to timeout, while on an OSX machine, it took 148 seconds to timeout. On a Windows machine, it seems to work just fine (it timed out after the desired 3 seconds). Is this option fully supported for SSL sockets? -- assignee: christian.heimes components: SSL files: httpdelay.py messages: 295106 nosy: allanc, christian.heimes priority: normal severity: normal status: open title: SSL socket does not respect SO_RCVTIME0 timeouts type: behavior versions: Python 2.7, Python 3.5 Added file: http://bugs.python.org/file46922/httpdelay.py ___ Python tracker <http://bugs.python.org/issue30562> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20612] cElementTree has problems with StringIO object containing unicode content
New submission from Allan Crooks:
There seems to be a specific issue when using cElementTree.parse on a StringIO
object containing unicode text - it generates a ParseError.
I've tried variations of ElementTree and cElementTree, variations of StringIO
and cStringIO, and used str and unicode types. It seems there is one
combination of these that generates the problem. I tried this on Python 2.7.5 -
this bit of code shows the inconsistency we've got:
>>> from xml.etree import ElementTree as ET, cElementTree as CET
>>> from StringIO import StringIO as SIO
>>> from cStringIO import StringIO as CSIO
>>> xml, uxml = '', u''
>>>
>>> def parse(etree_impl, strio_class, text):
... try:
... return etree_impl.parse(strio_class(text))
... except Exception as e:
... return 'ERROR: ' + repr(e)
...
>>> for etree_var in 'ET CET'.split():
... for sio_var in 'SIO CSIO'.split():
... for xml_var in 'xml uxml'.split():
... print etree_var, sio_var, xml_var,
... print parse(vars()[etree_var], vars()[sio_var], vars()[xml_var])
...
ET SIO xml
ET SIO uxml
ET CSIO xml
ET CSIO uxml
CET SIO xml
CET SIO uxml ERROR: ParseError('no element found: line 1, column 0',)
CET CSIO xml
CET CSIO uxml
--
components: XML
messages: 24
nosy: amcone
priority: normal
severity: normal
status: open
title: cElementTree has problems with StringIO object containing unicode content
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue20612>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4643] cgitb.html fails if getattr call raises exception
Allan Crooks added the comment: In the interests of getting this fixed (and not letting it die), should I submit a proper patch? I suppose I would have to do one for each version of Python that is affected (which is all of them, really). ___ Python tracker <http://bugs.python.org/issue4643> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4643] cgitb.html fails if getattr call raises exception
Allan Crooks added the comment: In terms of patching scanvars, I came up with the following solution: ORIGINAL: if parent is not __UNDEF__: value = getattr(parent, token, __UNDEF__) vars.append((prefix + token, prefix, value)) SOLUTION: if parent is not __UNDEF__: try: value = getattr(parent, token, __UNDEF__) except Exception: value = __UNDEF__ vars.append((prefix + token, prefix, value)) I think this makes the most sense - it requires a small change, and it won't have any strange side effect. One slightly undesirable aspect is that for an attribute value which could not be determined (due to this problem), it will say that it was "undefined", which isn't entirely accurate. My initial patch changed value to be a string to be "could not determine value", but if the line of code looked like this: print 'B:', weird.b.upper() Then for something which shouldn't work, it would determine that the value of weird.b.upper is the string method - which isn't what we're after. So I would recommend my original patch (as described above) as the best solution. ___ Python tracker <http://bugs.python.org/issue4643> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4643] cgitb.html fails if getattr call raises exception
Changes by Allan Crooks : -- type: -> behavior ___ Python tracker <http://bugs.python.org/issue4643> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4644] Minor documentation fault in 2to3 script
New submission from Allan Crooks : When I run the following command: C:\temp>\python26\Tools\scripts\2to3.py --help Usage: refactor.py [options] file|dir ... It mentions that the script name is refactor.py, rather than 2to3.py (I guess that was the scripts original name?) -- components: 2to3 (2.x to 3.0 conversion tool) messages: 77673 nosy: amc1 severity: normal status: open title: Minor documentation fault in 2to3 script type: behavior versions: Python 2.6, Python 3.0 ___ Python tracker <http://bugs.python.org/issue4644> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4643] cgitb.html fails if getattr call raises exception
New submission from Allan Crooks : If cgitb.html tries to get the value of an attribute from an object, and the getattr call causes an exception to be raised (other than an AttributeError), then cgitb.html fails to work: If you run the attached file in Python 2.5.2 or 2.6, you get the following output: A: the letter a B: Something went wrong - attempting to generate HTML stack trace. Error generating HTML stack trace! Traceback (most recent call last): File "attrtest.py", line 21, in html_text = cgitb.html(sys.exc_info()) File "C:\python26\lib\cgitb.py", line 133, in html vars = scanvars(reader, frame, locals) File "C:\python26\lib\cgitb.py", line 84, in scanvars value = getattr(parent, token, __UNDEF__) File "attrtest.py", line 8, in __getattr__ return str(slf) # Intentional NameError NameError: global name 'slf' is not defined The problem is in the scanvars function - it offers no protection against any unexpected exceptions that occur (that escape the getattr call) - which can be a problem if it is the same problematic code that caused cgitb.html to be called in the first place. I think scanvars should catch any exceptions that come from the getattr call and either mention that the attribute value could not be determined, or simply omit the mention of the attribute at all. If the line in the attached file is commented out, then the next line is caught appropriately and formatted correctly (the offending code occurs in the same block, but doesn't cause the same problem because it raises an AttributeError). -- components: Library (Lib) files: attrtest.py messages: 77672 nosy: amc1 severity: normal status: open title: cgitb.html fails if getattr call raises exception versions: Python 2.5.3, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file12330/attrtest.py ___ Python tracker <http://bugs.python.org/issue4643> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3622] Slight documentation quirk for random.random
New submission from Allan Crooks <[EMAIL PROTECTED]>: The documentation for random.random function shows this: random() -> x in the interval [0, 1). That should either be "[0, 1]" or "(0, 1)". -- assignee: georg.brandl components: Documentation messages: 71582 nosy: amc1, georg.brandl severity: normal status: open title: Slight documentation quirk for random.random type: behavior versions: Python 2.3, Python 2.4, Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3622> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
