Expect:100-continue support?

[Nikratio]

Hello,

It seems to me that httpcore currently does not support the use of Expect: 100-continue (unless I've missed something?).

Is that a deliberate design decision, or would a patch to add this functionality be considered?

I did a bit of research, and it seems the underlying h2 module supports this, we just have to make it available in httpcore as well. Without changes to httpcore, the only way to use this seems to be to subclass AsyncHTTP2Connection/AsyncHTTP11Connection and overwrite the handle_async_request method (while copying & pasting most of the existing implementation).

[TayfurYldz]

There are two different meanings of "supports 100 Continue" here.

Current httpcore already understands an informational HTTP/1.1 100 response: there are sync and async regression tests named test_http11_expect_continue, and the receive path ignores the interim response and returns the final response. That was fixed in #605.

What it does not implement is the client-side Expect/Continue handshake you are asking for: send headers with Expect: 100-continue, pause the request body, wait for either 100 or a final response, then decide whether to transmit the body. In both current HTTP/1.1 paths, handle_request calls send_request_headers, then send_request_body, and only afterwards receive_response_headers. So merely adding the header does not defer a large upload.

HTTP/2 is a separate point. h2 can represent informational responses, but HTTP/2 does not need Expect: 100-continue for framing in the same way HTTP/1.1 does, and httpcore's current HTTP/2 request path likewise sends headers/body before receiving response headers.

So I would frame a patch narrowly around HTTP/1.1 request sequencing rather than exposing something from h2. The important cases to pin in tests are: 100 -> send body -> final response; final response (for example 417) before 100 -> do not send body; timeout/no interim response -> define whether/when the body proceeds; and sync/async parity.

That likely needs an explicit state/flow in HTTP11Connection rather than subclassing and copying handle_request. The current interim-response support gives you the receive-side primitive, but not the body-gating behavior.