New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SSLSocket.recv(0) receives up to 1024 bytes #67992
Comments
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: >>> import socket, ssl
>>> s = ssl.wrap_socket(socket.create_connection(("localhost", 631)))
>>> s.sendall(b"GET / HTTP/1.1\r\nHost: localhost\r\n\r\n")
35
>>> len(s.recv(0))
263
>>> len(s.recv(0))
1024 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. |
New changeset 7a3c5f7dda86 by Martin Panter in branch '3.5': New changeset 72c457f9533a by Martin Panter in branch 'default': New changeset f4cff2bf9903 by Martin Panter in branch '2.7': |
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.) |
New changeset 74856df7e55b by Martin Panter in branch '3.5': New changeset 43d7e5fb3bc2 by Martin Panter in branch '2.7': New changeset 4ef2404d343e by Martin Panter in branch 'default': |
New changeset df908a9d97a6 by Martin Panter in branch 'default': |
Oops, that last merge is not related to this |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: