2026-09-18 · 6 min read · Rahul Chitturi
- http
- uploads
- proxies
A client can send Expect: 100-continue before a large request body so the server can reject an unauthorized or oversized request without receiving every byte. The client sends headers, waits briefly for an interim response, and sends the body after 100 Continue or its fallback timeout.
Uploads can stall when a proxy strips the expectation, buffers the body, suppresses the interim response, or waits for an upstream body that the client is still withholding.
Separate interim and final responses
Capture a timeline for request headers, any 100 response, first body byte, final response, and connection close. A 100 response is not the application result; the client must continue reading for the final status.
- Confirm which hop added the Expect header.
- Record client and proxy continue-wait timeouts.
- Check whether authentication runs before body consumption.
- Treat an early final status as a reason not to send the body.
Inspect every HTTP hop
Gateways may translate protocol versions, buffer uploads, enforce independent size limits, or generate their own responses. Compare direct-to-origin behavior with the complete production path using harmless fixture data.
Do not fix a deadlock by blindly disabling limits or extending every timeout. Decide whether the endpoint benefits from the handshake, then configure clients and intermediaries around one documented policy.
Build a bounded upload matrix
Use the URL tool to inspect the target, timestamp converter for event timelines, units converter for size thresholds, and diff for sanitized header sets.
Test accepted and rejected authorization, bodies below and above limits, immediate and delayed 100 responses, an early final error, no interim response, redirects, retries, connection reuse, chunked and fixed-length bodies, and each production proxy.