This seems more like a new feature than a bug fix to me. Currently the behaviour is the same whether “Expect: 100-continue” is requested or not. According to <https://tools.ietf.org/html/rfc7231#page-35>, the client does not have to wait any specific length of time for the “100 Continue” response, so sending the body straight away is okay.

In current releases (2.7, 3.4), maybe it would be good enough to document that the body is always sent without waiting, even if “Expect: 100-continue” is requested.

Considering this as a new feature, the new exceptions don’t seem very flexible to me. What is the use case, or what would your code look like? If I wanted to use the expectation feature of HTTP, I think I would want to know the reason why “100 Continue” was not received, and the blanket ContinueExpected exception is not going to be very helpful with that. Maybe I am being redirected somewhere else first, or maybe I have to log in with some kind of authentication, etc, but there is no way to get the relevant Location, WWW-Authenticate, etc fields.

Some more comments specifically about issue1346874-273.patch:

* The documentation should say what the behaviour is when “Expect: 100-continue” is requested. Point out that some sort of response is expected from the server before sending the body, and if the server does not send such a response the request will deadlock or time out.

* __all__ would need updating with the new exceptions

* “100 Continue” responses should still be read even when the expectation field is not in the request (and presumably, second and subsequent “100 Continue” responses should also be skipped even when the expectation is enabled). If there is not a test for this, one should probably be added.