Message 8324 - Python tracker

➜

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author	loewis
Recipients
Date	2001-12-29.01:18:58
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to

Content
Logged In: YES user_id=21627 The problem does not lie in the urllib module, and likely also not in the SSL support in the socket module. Please refer to the attached https.py. On a server that does an orderly SSL shutdown (e.g. sf.net), this raises socket.sslerror: (6, 'TLS/SSL connection has been closed') or socket.SSL_ERROR_ZERO_RETURN. On wwws.task.com.br, it prints HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Sat, 29 Dec 2001 00:50:32 GMT Content-Type: text/html Accept-Ranges: by tes Last-Modified: Tue, 18 Dec 2001 21:17:02 GMT ETag: "05be155988c11:85f" Content-Length: 80 <HTML> <HEAD><TITLE>HTTPS Test</TITLE></HEAD> <BODY>HTTPS Test</BODY> </HTML> Traceback (most recent call last): File "https.py", line 16, in ? buf = ssl.read() socket.sslerror: (5, 'EOF occurred in violation of protocol') So I still think that the bug is on the server side (Microsoft IIS, in this case), which does not perform proper connection shutdown, but just closes the connection. This problem went unnoticed in 2.1, since httplib.FakeSocket.makefile would read until any kind of exception occurred, then consider the exception as the end of the conversation. This was bug #458835; Jeremy fixed it in httplib.py 1.41. I don't think we should restore the 2.1 behaviour. In the specific case of IIS, the best thing would be to honor the Content-length, i.e. not try to read more than content-length bytes; that would require implementing a true file-like object, instead of re-using StringIO. The best work-around (for this case, and the general case of a server violating the SSL protocol) is to special-case socket.SSL_ERROR_SYSCALL in addition to SSL_ERROR_ZERO_RETURN, perhaps checking for the message ""EOF occurred in violation of protocol" (since this message is generated inside Python). In summary, I agree with Jeremy that these changes were for the better...

Logged In: YES 
user_id=21627

The problem does not lie in the urllib module, and likely
also not in the SSL support in the socket module. Please
refer to the attached https.py.

On a server that does an orderly SSL shutdown (e.g. sf.net),
this raises
socket.sslerror: (6, 'TLS/SSL connection has been closed')
or socket.SSL_ERROR_ZERO_RETURN. On wwws.task.com.br, it prints

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Sat, 29 Dec 2001 00:50:32 GMT
Content-Type: text/html
Accept-Ranges: by
tes
Last-Modified: Tue, 18 Dec 2001 21:17:02 GMT
ETag: "05be155988c11:85f"
Content-Length: 80


<HTML>
<HEAD><TITLE>HTTPS Test</TITLE></HEAD>
<BODY>HTTPS Test</BODY>
</HTML>
Traceback (most recent call last):
  File "https.py", line 16, in ?
    buf = ssl.read()
socket.sslerror: (5, 'EOF occurred in violation of protocol')
So I still think that the bug is on the server side
(Microsoft IIS, in this case), which does not perform proper
connection shutdown, but just closes the connection.

This problem went unnoticed in 2.1, since
httplib.FakeSocket.makefile would read until any kind of
exception occurred, then consider the exception as the end
of the conversation. This was bug #458835; Jeremy fixed it
in httplib.py 1.41.
I don't think we should restore the 2.1 behaviour. In the
specific case of IIS, the best thing would be to honor the
Content-length, i.e. not try to read more than
content-length bytes; that would require implementing a true
file-like object, instead of re-using StringIO.

The best work-around (for this case, and the general case of
a server violating the SSL protocol) is to special-case
socket.SSL_ERROR_SYSCALL in addition to
SSL_ERROR_ZERO_RETURN, perhaps checking for the message
""EOF occurred in violation of protocol" (since this message
is generated inside Python).

In summary, I agree with Jeremy that these changes were for
the better...

History
Date	User	Action	Args
2007-08-23 13:58:10	admin	link	issue494762 messages
2007-08-23 13:58:10	admin	create