Antoine Pitrou added the comment:
Actually, the test hangs after one of the threads crashes:
test__all__ (test.test_poplib.TestPOP3_SSLClass) ... Exception in thread
Thread-23:
Traceback (most recent call last):
File /home/antoine/cpython/default/Lib/threading.py, line 920, in
Antoine Pitrou added the comment:
Am I doing something wrong?
I can reproduce the failure here.
There might be different behaviour accross OpenSSL versions (mine is
1.0.1e).
--
___
Python tracker rep...@bugs.python.org
Nikolaus Rath added the comment:
Maybe. I have 1.0.1g. Could you maybe post the output of the failed test? I'd
like to understand how the patch broke the test (looking at your patch alone
didn't tell me much).
--
___
Python tracker
Roundup Robot added the comment:
New changeset 3cf067049211 by Antoine Pitrou in branch 'default':
Issue #20951: SSLSocket.send() now raises either SSLWantReadError or
SSLWantWriteError on a non-blocking socket if the operation would block.
Previously, it would return 0.
Roundup Robot added the comment:
New changeset b0f6983d63df by Antoine Pitrou in branch 'default':
Add porting note for issue #20951.
http://hg.python.org/cpython/rev/b0f6983d63df
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
Patch finally committed. Thanks Nikolaus!
--
resolution: - fixed
stage: patch review - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20951
Roundup Robot added the comment:
New changeset 7f50e1836ddb by Antoine Pitrou in branch 'default':
Fix failure in test_poplib after issue #20951.
http://hg.python.org/cpython/rev/7f50e1836ddb
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
Ok, there was a failure in test_poplib when run with -unetwork, I fixed it.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20951
___
Nikolaus Rath added the comment:
Antoine, are you sure this was a problem related to this patch?
The test seems to work just fine for me:
$ hg update -C -r b0f6983d63df
$ make clean
$ ./configure --with-pydebug make -j1
$ ./python -m test -u network,urlfetch -j 8 test_poplib
[1/1] test_poplib
Changes by Nikolaus Rath nikol...@rath.org:
Added file: http://bugs.python.org/file35082/issue20951_r3.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20951
___
Nikolaus Rath added the comment:
As discussed on python-dev, here is a patch that changes the behavior of send()
and sendall() to raise SSLWant* exceptions instead of returning zero.
--
Added file: http://bugs.python.org/file35062/issue20951_r2.diff
Antoine Pitrou added the comment:
I vote -1 to adding a new flag to control whether it returns zero or
raises and +0 to just fixing it in Python 3.5 (I don't think returning
zero is an unreasonable thing to do; it's not obvious to me from
send(2) that it is guaranteed to never return zero
Nikolaus Rath added the comment:
As an alternative, I have attached a pure docpatch that just documents the
future behavior.
Someone with commit privileges: please take your pick :-).
--
Added file: http://bugs.python.org/file34633/docpatch.diff
Antoine Pitrou added the comment:
There's a great saying in the usability world: You can't document
your way out of a usability problem.
However, adding a flag to change behaviour at runtime creates *another*
usability problem. It's not obvious it would actually make things better (and
Giampaolo Rodola' added the comment:
-1 about adding raise_on_blocking_send=False option as IMO it unnecessarily
complicates the API.
Note: when working with plain sockets send() returning 0 means the connection
has been closed by the other peer, same for os.sendfile().
It appears ssl module
Ben Darnell added the comment:
Giampaolo, where do you see that send() may return zero if the other side has
closed? I've always gotten an error in that case (EPIPE)
I vote -1 to adding a new flag to control whether it returns zero or raises and
+0 to just fixing it in Python 3.5 (I don't
Giampaolo Rodola' added the comment:
Sorry, my fault. I got confused with os.sendfile() which returns 0 on EOF.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20951
___
Nikolaus Rath added the comment:
On 03/25/2014 06:53 PM, Ben Darnell wrote:
Another option may be to have SSLSocket.send() convert the WANT_WRITE
exception into a socket.error with errno EAGAIN. This wouldn't break Tornado
and would make socket.send and SSLSocket.send more consistent, but
Nikolaus Rath added the comment:
(refreshed patch)
--
Added file: http://bugs.python.org/file34608/issue20951.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20951
___
Changes by Nikolaus Rath nikol...@rath.org:
Added file: http://bugs.python.org/file34540/issue20951.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20951
___
Nikolaus Rath added the comment:
I'd like to argue with the wise words of Nick Coghlan here:
--snip--
There's a great saying in the usability world: You can't document your way out
of a usability problem. What it means is that if all the affordances of your
application (or programming
Changes by Nikolaus Rath nikol...@rath.org:
Removed file: http://bugs.python.org/file34540/issue20951.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20951
___
Changes by Nikolaus Rath nikol...@rath.org:
Added file: http://bugs.python.org/file34541/issue20951.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20951
___
Antoine Pitrou added the comment:
I don't think complicating the situation by exposing two different kinds of
non-blocking sockets is the solution here.
Either we decide it is worth breaking compatibility and we change the behaviour
by default (I'm rather against this), or we simply document
Nikolaus Rath added the comment:
Since this behavior cannot be changed without breaking third-party libraries
(why did they work around this rather than reporting a bug?), I'd suggest to
document the current behavior and allow programs to opt-in to getting
exceptions.
I've attached a patch
Changes by R. David Murray rdmur...@bitdance.com:
--
stage: - patch review
type: behavior - enhancement
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20951
___
New submission from Nikolaus Rath:
When using non-blocking operation, the SSLSocket.send method returns 0 if no
data can be sent at this point.
This is counterintuitive, because in the same situation (write to non-blocking
socket that isn't ready for IO):
* A regular (non-SSL) socket raises
Nikolaus Rath added the comment:
This is actually seems to be not just an inconvience, but a real bug: since
SSLSocket.sendall() uses SSLSocket.send() internally, the former method will
busy-loop when called on a non-blocking socket.
Note also that the .sendto and .write methods already
R. David Murray added the comment:
A little hg sleuthing (which I assume you did but I'll record for the record)
reveals that this was introduced by Bill Jansen in changeset 8a281bfc058d.
Following the bugs mentioned in the checkin message, it looks like it *might*
have been related to issue
Antoine Pitrou added the comment:
It's probably too late to change this, unfortunately. There are non-blocking
frameworks and libraries out there relying on the current behaviour.
As for sendall(), it doesn't really make sense on a non-blocking socket anyway.
--
Nikolaus Rath added the comment:
Antoine, do you know that there are frameworks out there using this, or is that
a guess? asyncio, for example, seems to expect an SSLWantWrite exception as
well. (it also works with a zero return, but it's not clear from the code if
that's by design or by a
Antoine Pitrou added the comment:
Antoine, do you know that there are frameworks out there using this,
or is that a guess?
It's just a guess.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20951
Nikolaus Rath added the comment:
Twisted does not seem to rely on it either (there's no mention of SSLWant* in
the source at all, and without that, you can't possibly have support for
non-blocking ssl sockets).
--
___
Python tracker
Nikolaus Rath added the comment:
gevent is calling _sslobject.write() directly, so it would not be affected by
any change.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20951
___
Nikolaus Rath added the comment:
Tornado uses SSLSocket.send(), and it looks as if a SSLWantWrite exception is
not caught but would propagate, so this would probably break.
--
___
Python tracker rep...@bugs.python.org
Nikolaus Rath added the comment:
More info on twisted: it uses PyOpenSSL rather than the stdlib ssl module, so
it's not affected at all.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20951
36 matches
Mail list logo
