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.