How do I handle Expect: 100-continue when using BodyDataStream?

[Scripter17]

Summary

Code with the problem

The code contains a POST endpoint that reads the request body and sends a response body in parallel, allowing clients without access to a decent WebSocket client to process arbitrarily large jobs without having to manually break them up into smaller jobs.

The issue is that when using curl with a large payload, curl sends an Expect: 100-continue header and waits 1 second for a 100 response that isn't coming. All issues and discussions I could find seem to say that body extractors with finite limits correctly handle this by sending a 100 response then letting the handler return the real status, but there doesn't seem to be any way to mimic this while accepting arbitrarily large request bodies.

The timeline when using cargo run -p url-cleaner-site and yes https://example.com | head -n 1000000 | curl http://127.0.0.1:9149/clean --data-binary @- is

1. Curl sends an HTTP 1.1 POST request with the Expect header sent to 100-continue.
2. URL Cleaner Site responds with a 200 status and waits for curl to send the body.
3. Curl waits 1 second for a 100 response, completely ignoring the 200 response.
4. Curl gives up, accepting the 200 response.
5. Curl sends the body.
6. URL Cleaner Site returns the response.

What I need to do is somehow inject a "URL Cleaner Site notices the Expect header and sends a 100 status" between 1 and 2, thus skipping 3 and 4.

While I can pass -H Expect: to curl to disable the header and waiting, asking every user of a client that does this to find their client's equivalent seems unreasonable for a problem Rocket handles out of the box. Additionally, having the handler notice the header and return a 100 response makes what should be the real response instead be a 502 error.

axum version

0.8.8

[jplatte]

Can you try curl -v? Does it use HTTP 1.1 or HTTP 2.0? I saw in the h2 (crate used for HTTP 2.0 inside hyper) release notes from only 5d ago that they added support for 1xx responses: https://github.com/hyperium/h2/releases/tag/v0.4.13. Maybe you're using HTTP 2.0 but are still on an older version of h2? You can search your Cargo.lock.

[Scripter17]

(Using port 9148 because my main instance is on 9149 but it's the same thing)

*   Trying 127.0.0.1:9148...
* Connected to 127.0.0.1 (127.0.0.1) port 9148
* using HTTP/1.x
> POST /clean HTTP/1.1
> Host: 127.0.0.1:9148
> User-Agent: curl/8.14.1
> Accept: */*
> Content-Length: 19000000
> Content-Type: application/x-www-form-urlencoded
> Expect: 100-continue
> 
< HTTP/1.1 200 OK
< transfer-encoding: chunked
< date: Sun, 11 Jan 2026 00:46:26 GMT
< 
* Done waiting for 100-continue
} [65536 bytes data]
* upload completely sent off: 19000000 bytes
{ [65550 bytes data]
* Connection #0 to host 127.0.0.1 left intact

h2 is at 0.4.13, not that it's relevant here. Neither --http2-prior-knowledge nor --http2 work as described in curl's --help all. (Edit: They do, though Axum ignores http2 upgrades?)

Edit: I probably should clarify that I'm using a slightly updated version of the linked code that fixes a few bugs, but this particular issue behaves identically between the two versions. Just saying that now in case a proposed fix works on the linked code but not on my local copy.

[jplatte]

Okay. Well, I guess you should report this to hyper. You can copy paste or serve implementation and slim it down, it really doesn't do a while lot of interesting things. All the actually interesting logic is in hyper / hyper-util.