You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
SSLSocket.recv(0) receives up to 1024 bytes #67992
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=<Date2016-07-11.06:54:06.704>created_at=<Date2015-03-29.10:30:23.554>labels= ['type-bug', 'library']
title='SSLSocket.recv(0) receives up to 1024 bytes'updated_at=<Date2016-07-11.13:29:04.603>user='https://github.com/vadmium'
The documentation claims that SSL socket objects provide some of the same methods as plain socket objects, including recv(), and that the “bufsize” parameter specifies the maximum amount of data to be received. With ordinary sockets, socket.recv(0) always seems to return zero bytes (b""), as expected. But not so with SSL sockets:
The call will hang or raise SSLWantReadError when no data is actually available. Looking at the code, the value of zero seems to be used as a placeholder for a default of 1024 in SSLObject.read(). Either the SSL module should be fixed to return no bytes (my preference), or the documentation needs to warn that the recv(0) is not supported, or does not work the same as for plain sockets. SSLSocket.read() might also be affected.
Here is a patch for 3.5 that changes the default size to explicitly be 1024, and tests that recv(0) and read(0) now work as I expect they should by returning nothing.
This was not fixed properly. The first symptom is that recv(0) etc still blocks if the other end sends no data. The second symptom is that it does not work with suppress_ragged_eofs=False. The problem is SSL is still called to do a read, which returns zero, and that seems to be interpreted as some kind of EOF or shutdown indicator.
(IMO suppress_ragged_eofs=True is a bad default. It essentially treats a man-in-the-middle shutdown as a genuine secure shutdown, but that would be a separate issue.)
Activity
vadmium commentedon Mar 29, 2015
The documentation claims that SSL socket objects provide some of the same methods as plain socket objects, including recv(), and that the “bufsize” parameter specifies the maximum amount of data to be received. With ordinary sockets, socket.recv(0) always seems to return zero bytes (b""), as expected. But not so with SSL sockets:
The call will hang or raise SSLWantReadError when no data is actually available. Looking at the code, the value of zero seems to be used as a placeholder for a default of 1024 in SSLObject.read(). Either the SSL module should be fixed to return no bytes (my preference), or the documentation needs to warn that the recv(0) is not supported, or does not work the same as for plain sockets. SSLSocket.read() might also be affected.
vadmium commentedon May 15, 2015
Here is a patch for 3.5 that changes the default size to explicitly be 1024, and tests that recv(0) and read(0) now work as I expect they should by returning nothing.
python-dev commentedon Mar 28, 2016
New changeset 7a3c5f7dda86 by Martin Panter in branch '3.5':
Issue bpo-23804: Fix SSL recv/read(0) to not return 1024 bytes
https://hg.python.org/cpython/rev/7a3c5f7dda86
New changeset 72c457f9533a by Martin Panter in branch 'default':
Issue bpo-23804: Merge SSL zero read fix from 3.5
https://hg.python.org/cpython/rev/72c457f9533a
New changeset f4cff2bf9903 by Martin Panter in branch '2.7':
Issue bpo-23804: Fix SSL recv/read(0) to not return 1024 bytes
https://hg.python.org/cpython/rev/f4cff2bf9903
vadmium commentedon Jun 27, 2016
This was not fixed properly. The first symptom is that recv(0) etc still blocks if the other end sends no data. The second symptom is that it does not work with suppress_ragged_eofs=False. The problem is SSL is still called to do a read, which returns zero, and that seems to be interpreted as some kind of EOF or shutdown indicator.
(IMO suppress_ragged_eofs=True is a bad default. It essentially treats a man-in-the-middle shutdown as a genuine secure shutdown, but that would be a separate issue.)
python-dev commentedon Jul 11, 2016
New changeset 74856df7e55b by Martin Panter in branch '3.5':
Issue bpo-23804: Fix SSL zero-length recv() calls to not block and raise EOF
https://hg.python.org/cpython/rev/74856df7e55b
New changeset 43d7e5fb3bc2 by Martin Panter in branch '2.7':
Issue bpo-23804: Fix SSL zero-length recv() calls to not block and raise EOF
https://hg.python.org/cpython/rev/43d7e5fb3bc2
New changeset 4ef2404d343e by Martin Panter in branch 'default':
Issue bpo-23804: Merge SSL recv() fix from 3.5
https://hg.python.org/cpython/rev/4ef2404d343e
python-dev commentedon Jul 11, 2016
New changeset df908a9d97a6 by Martin Panter in branch 'default':
Issue bpo-23804: Merge spelling and NEWS fixes from 3.5
https://hg.python.org/cpython/rev/df908a9d97a6
vadmium commentedon Jul 11, 2016
Oops, that last merge is not related to this