Antoine Pitrou pit...@free.fr added the comment:
This is not a bug. With a non-blocking socket, the handshake itself is
non-blocking, so you have to be prepared to retry. Your snippet also fails
under Python 2.6 for me, so this isn't a regression either.
If you want to know how to do a
Jesús Cea Avión j...@jcea.es added the comment:
I am not getting the error in the handshake. I am getting it when transfering
data, after a few Kbytes are already transfered.
This code has been working for the last 8 years, including 2.7.1. It is failing
now, under 2.7.2. OpenSSL version
Jesús Cea Avión j...@jcea.es added the comment:
I am talking about the code in production, not the code I pasted yesterday.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12343
___
Antoine Pitrou pit...@free.fr added the comment:
I am not getting the error in the handshake. I am getting it when
transfering data, after a few Kbytes are already transfered.
Your traceback (and mine as well) occurs in wrap_socket() which itself calls
do_handshake(). I don't understand how
Antoine Pitrou pit...@free.fr added the comment:
Ah, ok, looks like your messages crossed each other. Can you try to devise
another test case, then?
Or, at least, explain the context and how and where it fails?
--
___
Python tracker
Jesús Cea Avión j...@jcea.es added the comment:
Protecting my reads retrying when getting this exception does the trick, but
now my code is convoluted and never before I had to manage this directly. This
worked fine in 2.7.1. Previously Python seemed to do the retry itself.
--
Antoine Pitrou pit...@free.fr added the comment:
Note: the only significant changes in the ssl module on branch 2.7 have been
742d73a99425 and 7f99ac53014a.
Protecting my reads retrying when getting this exception does the
trick, but now my code is convoluted and never before I had to manage
Jesús Cea Avión j...@jcea.es added the comment:
I have write a testcase, but adding a small delay between reads, allowing more
data coming from the server, solves the issue, so this seems to be a race
condition. Trying with a remote slow SSL server, I get the same error in python
2.6, so I
STINNER Victor victor.stin...@haypocalc.com added the comment:
It's maybe because Python 2.7.2 is faster/slower? :-)
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12343
___
Jesús Cea Avión j...@jcea.es added the comment:
Antoine, now I am worried about writes, since my usual aproach would be
something like this:
select says that it is Ok to try to write
buf = buf[socket.send(buf):]
If now I can get a retry while writing, what is the logic?. Does Python retry
Antoine Pitrou pit...@free.fr added the comment:
If now I can get a retry while writing, what is the logic?. Does
Python retry automatically, internally?.
No, Python doesn't retry automatically. You have to call send() again with the
same buffer.
(if Python retried, it would make
New submission from Jesús Cea Avión j...@jcea.es:
Combining non-blocking SSL sockets and select() raises ssl.SSLError: [Errno
2] _ssl.c:503: The operation did not complete (read) in Python 2.7.2, but
works OK in 2.7.1, 2.6.* and previous.
This test shows the issue:
import ssl
import socket
12 matches
Mail list logo