> Calling self.wfile.write(b"") should be equivalent to not calling write() at all, as far as I understand.

Right (or at least, as I understand it as well).

Really, this boils down to a philosophical debate: Should the standard library account for unexpected conditions where possible (within reason of course), or should it only account for conditions as described by specifications?

> 1. Client connects to server and sends short request; server accepts connection and possibly reads request
> [snip]

This flow makes sense and is well accounted for with your proposed change. However, misbehaving cases such as:

1. Client connects to server or proxy (possibly through a tunnel) and sends request; server/proxy accepts connection and possibly reads request
2. Server/proxy intends to send a response, but doesn't for any number of reasons (bug, still in development, etc)
3. The connection is not closed and subsequent requests may succeed

Granted, the result is unexpected and doesn't comply with HTTP RFCs. However, leading the user to believe that the connection has been closed when it actually hasn't is misleading. I've spent many an hour trying to hunt down root causes of issues like this and bashed my head against a keyboard in disbelief when I found out what the cause /really/ was. Because of those headaches, I still think that the introduction of an UnexpectedResponse, if well documented, covers both cases nicely, but won't heatedly argue it further :) If others (namely core devs) think that the introduction of ConnectionClosed exception is a better way to go, then I'll bow out. It would maybe be nice to have Senthil chime in on this.


> But to address your concern in any case, see the third paragram in <https://bugs.python.org/issue3566#msg234330>.

I don't think that should be added at all as the issue that I'm describing can occur at any point, not only the first request.


On another note, were you interested in submitting a patch for this?