How to Test Expect: 100-continue Through a Proxy Before Large Uploads

Large uploads are expensive to repeat. HTTP Expect: 100-continue gives an HTTP/1.1 client a chance to send headers first, wait briefly, and avoid transmitting a large body when the server can already reject the method, path or credentials. A proxy can break that benefit by stripping the header, swallowing the interim response, delaying it beyond the client timer, inventing a response at the wrong hop or forwarding the body before a final rejection.

This guide builds a controlled acceptance test for proxy buyers and operators. Use an endpoint and files you own or are authorized to test; never probe third-party upload services without permission.

Understand the expected exchange

The client sends the request line and headers, including Expect: 100-continue, while holding the body. A compliant HTTP/1.1 origin can immediately send a final rejection based on those headers, or send 100 Continue and later produce one final response after the body arrives. An intermediary normally forwards informational responses unless it generated the expectation itself.

The client cannot wait forever. If no interim or final response arrives within its configured expectation timer, it may begin sending the body. That timeout is a client decision, so the test must capture timing rather than assume every library behaves alike.

HTTP/2 and HTTP/3 can stop request streams without closing the entire connection, so clients may not use this mechanism in the same way. Record the effective protocol on each side of the proxy instead of assuming an HTTP/1.1 exchange survives translation unchanged.

Build an owned upload fixture

Create a laboratory endpoint with four deterministic modes:

Use generated, non-sensitive payloads at several sizes. Record a payload digest, declared length, received length and final digest. The server should count bytes received before and after it sends each response.

Capture evidence by phase

For each attempt, record:

test_id
route_alias
client_version
client_to_proxy_protocol
proxy_to_origin_protocol
expect_header_seen
first_interim_status
time_to_interim_ms
body_send_start_ms
bytes_before_final
final_status
received_bytes
payload_digest_match
connection_reused
retry_count

Hash route and session identifiers. Do not record proxy passwords, authorization headers, cookies, tokens or private payloads.

Establish a direct baseline

Run every mode without a proxy using the exact production client. Confirm that acceptance sends one body after the 100 response, a header-only 401 sends no body, a 417 follows the client's documented policy, and the delayed mode exposes the actual expectation timer.

Repeat with small and large payloads. Some clients add or suppress Expect based on body size, method or whether the length is known. Capture the wire behavior; command-line configuration alone is not proof.

Add one proxy path at a time

Test each gateway, region, authentication method and address family separately. Keep the client, payload, endpoint and timeout unchanged. Compare:

• whether the origin saw the Expect header;
• whether the client saw 100 Continue;
• whether the body began before the interim response;
• whether a final rejection stopped body transmission;
• whether protocol translation changed the sequence;
• whether the connection remained reusable after the final response.

Use the proxy request-header integrity test when the header disappears or changes. Pair the final result with the proxy response-integrity test.

Test rejection without wasting bandwidth

In the unauthorized mode, issue a request with deliberately invalid laboratory credentials. The endpoint should return a final 401 from headers alone. A healthy path should not upload the large body after that final response.

Measure bytes accepted by the origin and bytes transmitted by the client. A proxy may buffer data even when the origin receives none, so both viewpoints matter. Never use real credentials in a negative test.

Handle 417 safely

A 417 Expectation Failed means the expectation was not supported along the response chain. Some clients may repeat the request without Expect. That does not make every automatic retry safe.

Allow a repeat only when the application knows the first attempt did not apply the operation or when the upload uses an idempotency mechanism accepted by the service. Bound the request count, elapsed time and bytes. Use the retry-storm prevention guide before enabling fallback at scale.

Diagnose common failure patterns

Do not label every delay as poor exit-IP quality. This is a message-flow and timing problem until route evidence proves otherwise.

Set an acceptance gate

A route passes when the accept mode produces one verified body and one final response; header-only rejection prevents unnecessary upload; interim and final responses remain ordered; timers are bounded; retries cannot duplicate application effects; and logs expose the failing phase without secrets.

Also track time to interim response, saved bytes on rejection, complete-upload rate, duplicate-body rate, final response latency and cost per verified upload. Raw throughput alone cannot show whether the handshake is correct.

Release checklist

• Direct behavior is known for the exact client version.
• Small, large, known-length and streamed bodies are tested.
• Client-to-proxy and proxy-to-origin protocols are recorded.
• Accept, 401, 417 and delayed modes are covered.
• Origin and client byte counters are compared.
• One accepted request creates exactly one application result.
• A final rejection stops the body.
• Expect timers and overall upload deadlines are bounded.
• Retries require safe replay or idempotency.
• Logs exclude credentials and private content.

FAQ

Should every upload use Expect: 100-continue?

No. The extra round trip can cost more than it saves for small bodies. Test the production client's size threshold and the rejection likelihood.

Is a missing 100 response always a proxy failure?

No. The server can send an immediate final response, and a client may begin after its timer expires. Compare direct and proxied wire evidence.

Does 100 Continue mean the upload succeeded?

No. It only means the initial request has not yet been rejected. The client must still receive and validate the final response.

Should a 417 rotate the proxy exit?

No. It describes expectation support in the response chain, not residential IP reputation. Diagnose the protocol path before changing routes.

Compliance note

Run upload and rejection tests only against systems you own or are explicitly authorized to test. Respect service limits, data-handling rules and proxy policies. Use synthetic payloads, minimize retention and never use proxy rotation to bypass an upload denial or access control.