[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Antoine Pitrou added the comment: Ok, I should have fixed the original issue. If you want to see an option to enable partial writes, please open a separate issue. -- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed __

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Roundup Robot added the comment: New changeset 60310223d075 by Antoine Pitrou in branch 'default': Issue #8240: Set the SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER flag on SSL sockets. http://hg.python.org/cpython/rev/60310223d075 -- nosy: +python-dev ___ Pyt

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Antoine Pitrou added the comment: > As for partial writes, I'm not sure if it's backwards compatible to > turn them on by default, but it might be nice if the option were > exposed. Partial writes may have less benefit in Python than in C > since we'd have to reallocate and copy a string instead

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Ben Darnell added the comment: I vote for enabling SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER by default. It can catch mistakes (i.e. failure to check the return value of send) in Python just as easily as in C, but I don't think those mistakes are common enough to be worth the headache of this error

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Antoine Pitrou added the comment: I'm thinking that perhaps we should simply enable SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER by default. Ben, what do you think? Does the current behaviour allow to catch bugs? -- type: behavior -> enhancement versions: +Python 3.4 -Python 3.3 __

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Changes by Ken Giusti : -- nosy: +Ken.Giusti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Ben Darnell added the comment: Related pypy issue: https://bugs.pypy.org/issue1238 -- nosy: +Ben.Darnell ___ Python tracker ___ ___ Pyt

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Antoine Pitrou added the comment: See issue12197 for a related request. -- versions: +Python 3.3 -Python 3.2 ___ Python tracker ___ __

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Antoine Pitrou added the comment: Patch should probably be rewritten to add a `mode` property on the new SSLContext object instead. -- ___ Python tracker ___ ___

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Changes by Antoine Pitrou : -- stage: commit review -> needs patch versions: +Python 3.2 -Python 2.6, Python 2.7 ___ Python tracker ___ ___

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Antoine Pitrou added the comment: > Wouldn't it be nicer if mode was a property? Good point. I guess it would indeed... -- ___ Python tracker ___ ___

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Benjamin Peterson added the comment: Wouldn't it be nicer if mode was a property? -- ___ Python tracker ___ ___ Python-bugs-list maili

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Antoine Pitrou added the comment: The patch adds a new feature, which makes it unsuitable for 2.6. I guess it could be applied to the 2.7 trunk, although a beta is being released and I'm not sure new features are really welcome afterwards. This one is really small and non-controversial, thoug

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Cyril added the comment: Here is a patch that implements SSLSocket.get_mode/set_mode, with the SSL_MODE_ENABLE_PARTIAL_WRITE and SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER constants defined in the ssl module. The patch contains a test case and documentation. It's made against trunk 44327 and also a

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Cyril added the comment: I had a look at how M2Crypto and pyOpenSSL handled this: - M2Crypto has wrappers around SSL_set_mode that let you set the modes you want. From their changelog [1], it was required to be able to operate with Twisted. By default, though, they only set SSL_MODE_AUTO_RET

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Antoine Pitrou added the comment: > If socket.write() returns zero byte written, I'll have to wait until I > get another chance to send my buffer. But in the meantime, some more > data might get appended to the buffer, and the string returned by > getvalue() will be different from the first call

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Cyril added the comment: > Hmm, indeed. What you can do, very simply, is cache the getvalue() > result once you have generated it. After some thoughts, it's not really an option: my cStringIO.StringIO buffer is, well a buffer. To append data to the buffer, I call buffer.write(). When I've got

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

STINNER Victor added the comment: > ..., the doc says about SSLSocket.write: > > Returns the number of bytes written. > > It actually either returns 0 or len(data), at least as long as we don't > have SSL partial writes. That's a different behaviour from regular > sockets, and I had to look

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Cyril added the comment: Switching to a documentation issue is fine to me. Indeed I can just cache the result of StringIO.getvalue(), although it feels a bit crude. I won't be able to create a documentation patch since English is not my primary language. While you're at it, the doc says about

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Antoine Pitrou added the comment: > pitrou: that's debatable, since the Python programmer has no control > over memory pointers. No, but he has control over whether he always uses the same object, or generates a new argument everytime. > As I said, I have a cStringIO buffer, and two consecuti

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Cyril added the comment: pitrou: that's debatable, since the Python programmer has no control over memory pointers. As I said, I have a cStringIO buffer, and two consecutive calls to buffer.getvalue() yield different objects. What can I do about it? I think it's a rather sane scenario, and I

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Cyril added the comment: r.david.murray: ah, sure :) However, I'm not sure a test case is absolutely required for this issue for two reasons: - the fix is trivial: it's a one-liner that enables a SSL mode that explicitely authorizes SSL_write to be called a second time with a a different me

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Antoine Pitrou added the comment: Since this error seems to be aimed at warning about potential programming errors, I'm not sure it should be silenced. The obvious fix should be to pass the same argument every time (until the data finally gets written). -- nosy: +pitrou _

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Changes by Antoine Pitrou : -- nosy: +janssen ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

R. David Murray added the comment: "test needed" is in reference to your assertion that you weren't sure your test would fail reliably. A test that fails some times and passes some times is...suboptimal when dealing with a buildbot testing infrastructure :) -- nosy: +r.david.murray

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Cyril added the comment: I forgot to talk about the conditions in which I stumbled upon that bug. I use a cStringIO.StringIO as a send buffer. When the socket is ready to send data, I call ssl_socket.send(send_buffer.getvalue()). Unfortunately, two consecutive calls to send_buffer.getvalue()

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Cyril added the comment: You're right about the assert, I've just uploaded a new patch. In non-blocking mode, ssl_socket.send(data) will return either 0 (which means nothing was sent, you'll have to try again), or len(data) when everything was sent. It can't return anything inbetween. This is

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

STINNER Victor added the comment: If I understood correctly, the patch only concerns non blocking socket if SSL_write() returns 0? If SSL_write() returns a non zero value, can you use: ssl_socket.send(data[count:])? About the string identifier trick, you should add an assertion to ensure that

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Changes by R. David Murray : -- priority: -> normal stage: -> test needed type: -> behavior ___ Python tracker ___ ___ Python-bugs-l

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Changes by R. David Murray : -- components: +Extension Modules -Library (Lib) nosy: +giampaolo.rodola ___ Python tracker ___ ___ Python

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

Cyril added the comment: The following test case exhibits the bug, but I'm not sure it will fail every time as it depends on 2 things: - your connection speed (I guess) - I used the following trick to have 2 identical strings with a different id (memory address): data = (('xx'[0] + 'xx'[1:

[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets

New submission from Cyril : ssl.SSLSocket.write on non-blocking sockets will fail with: _ssl.c:1217: error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write retry on a write retry, if the buffer address has changed between the initial call and the retry (when the initial call returned 0 bytes