Nathaniel Smith <n...@pobox.com> added the comment:

The current default is hard to defend -- it's a clear violation of the TLS 
specs. But I suspect that changing it will be pretty disruptive, because 
suppress_ragged_eof=True is the de facto standard for HTTP-over-TLS (generally 
justified on the grounds that HTTP has its own framing, so the TLS-level 
close-notify stuff is redundant), and that means that if we flip it cases that 
used to work correctly will start raising errors. We could avoid some of these 
issues by making http.client explicitly use suppress_ragged_eof=True, but then 
that won't fix Martin's problems...

A discussion about changing it should also consider what to do on 
sslsock.close(), since right now Python always gives the other side a "ragged 
eof" unless you call "sslsock.unwrap()", and I've never seen any code that does 
this. So flipping the suppress_ragged_eof default by itself will make Python's 
ssl module fail at interoperating with itself.

> 1. Truncate Set-Cookie field, with no terminating newline. [...] Python 
> (unpatched) treats the Set-Cookie field as valid. It appears in the 
> HTTPResponse object, with no clue that it was truncated.

This sounds like a bug in http.client – the lack of terminating newline should 
cause a parse failure regardless of what the SSL layer does (and regardless of 
whether we're even using SSL).

> 2. Content-Length response with truncated text/html. [...] In most cases, 
> Python raised an IncompleteRead exception, but it depended on the pattern of 
> read calls

Also a bug in http.client.

> 3. “Connection: close” response with truncated HTML:

This one's a little more interesting... First, "Connection: close" doesn't 
affect the framing of the HTTP body, it just says that this connection can't be 
reused for another request afterwards. The way HTTP works, if you have a 
response with neither a Content-Length header *nor* a Transfer-Encoding: 
chunked header, then it's assumed that the framing is determined by the 
connection being closed -- I assume that this is what you generated here. Now, 
this is a hack for backwards compatibility with HTTP/1.0; in theory, no modern 
server should ever generate such a response. In practice, who knows, people do 
all kinds of nonsense.

But... do we really think that servers who can't be bothered to implement 
HTTP/1.1, are also going to take the trouble to make sure their SSL/TLS 
handling is correct to the spec? If the server decides to use connection-close 
framing, that's their decision, and the client is kind of at their mercy.

----------
nosy: +njs

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue27815>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to