Uploads made with curl consistently stall for about a second before the request body is sent, and the stall disappears when the request goes direct instead of through a proxy. What is curl doing, and how would you confirm and remove the delay?

## The symptom Uploads work, results are correct, but every one takes about a second longer than it should — and the extra second does not scale with body size, which immediately rules out bandwidth. Small requests are unaffected. It appears only on one network path. ## What curl does by default curl adds `Expect: 100-continue` on its own when it is sending a body larger than about 1 KB (`PUT`, `POST` with a file, `--data-binary` of any size past the threshold). It then writes headers only and waits for the interim response before writing the body. If no response arrives within its internal expect-100 timeout — one second — curl gives up waiting and sends the body regardless. So the fixed one-second penalty is not a bug; it is the specified fallback doing its job against a peer that never answers. ## Why the proxy changes the outcome Intermediaries handle the expectation in incompatible ways: - Some **strip** the `Expect` header before forwarding, so the origin never sees it and never sends `100 Continue`; the proxy itself sends nothing either. - Some **drop 1xx responses** on the way back, because informational responses are easy to overlook when a proxy is written to relay one status line per request. The origin behaved correctly and curl still sees silence. - Some **buffer the whole request** before contacting the origin, which means they must read the body — so they wait for bytes while curl waits for a status. - Some **answer `100 Continue` themselves**, which removes the delay but also removes the benefit: the client uploads the full body to the proxy even if the origin will reject it. - A few legacy ones answer `417 Expectation Failed`, which costs a retry. Going direct to an origin that implements the mechanism produces an immediate `100 Continue` and no delay — exactly the difference described. ## Confirming it 1. `curl -v --trace-time` on the failing path. Look for `> Expect: 100-continue` in the request and for a `< HTTP/1.1 100 Continue` line. The timestamps place the gap precisely between headers and body — not in name resolution, connection setup or server processing. 2. Re-run with `-H 'Expect:'`. If the second disappears, the diagnosis is confirmed in one step. 3. If you need proof of who dropped what, capture packets or read proxy access logs; a proxy that strips the header will show a request to the origin without `Expect`. 4. Compare direct versus proxied with identical bodies to isolate the path. Be careful not to misattribute: a flat, size-independent delay before the first payload byte is the signature. If the delay scales with body size it is bandwidth; if it sits before the request line it is DNS, TCP or TLS; if it sits after the body it is server processing. ## Fixing it - **Client-side, immediate:** `curl -H 'Expect:'` sends the header with an empty value, which is curl's idiom for removing a header it would otherwise add. For scripted uploads this is the usual fix. - **Library clients:** Java's `HttpClient.Builder.expectContinue(false)`, Go's `Transport.ExpectContinueTimeout` (set small, or disable by not sending the header), Apache HttpClient's request config, urllib3/requests which do not send it by default at all. Shortening the timeout instead of disabling keeps the benefit when the peer does support it. - **Infrastructure:** make the proxy relay interim responses, or at least stop stripping `Expect`. This is the correct fix if large uploads genuinely benefit from early rejection. - **Decide deliberately:** if bodies are small, disable the expectation everywhere — it can only cost. If bodies are large and rejection is plausible (auth, quota, size limits), keep it and fix the path. ## The wider lesson An optional protocol optimization that depends on every hop understanding it will, on some paths, degrade into a fixed latency tax. The tell is a constant delay that does not scale with payload, and the debugging move is to compare paths while watching the wire rather than the application log.