Proxy 304 Responses: Reuse the Right Local Copy, Not an Empty Body

Start with the consumer, not the status counter

A research worker can finish a request without having new data to parse. If its code treats every successful network exchange as a fresh document, a conditional request can overwrite a valid snapshot with an empty file. The acceptance question is therefore: does this worker have the correct, usable local copy for this exact request context? This guide is for authorized monitoring and testing, not for bypassing access restrictions.

For conditional GET, an ETag sent in If-None-Match can lead to a 304 response without a document body. Weak validators are valid for that comparison; they do not establish byte-for-byte identity. These HTTP semantics follow RFC 9110. The workflow below is an application design proposal, not a measured compatibility or savings claim for every proxy route.

1. Define a representation key before retaining an ETag

Use a controlled endpoint you own, with a known content version and a small, non-sensitive fixture. Write down the final URL, selected market, requested language, authorized identity partition, and any other setting that changes the returned representation. Include the dimensions selected by Vary and the application's documented variation rules. Keep transport and content-encoding assumptions consistent during the first test.

Store that context together with the complete body, validator exactly as received, retrieval time, and a local integrity check. Treat the body and metadata as one record. A URL-only cache is inadequate when the same endpoint changes its offer or language by market or account. Do not retain credentials or raw cookies in diagnostic records; use an internal partition identifier.

2. Run three controlled transitions

Unchanged fixture: obtain version A with an ordinary GET, then send its validator in a second GET using the same request context. If the endpoint returns 304, keep A, record a validation event, and do not feed the empty wire body to the parser. Compare the parser's output with the original fixture.

Changed fixture: update the owned endpoint to version B. Repeat the conditional request with A's validator. Check that the resulting representation really contains B before replacing the body and validator together. An unconditional 200 on unchanged content is also a supported outcome to record; an endpoint might not offer conditional responses.

Missing-copy fixture: deliberately remove A's local body while leaving a test metadata entry. Your client should detect the missing copy before sending its validator. If an in-flight response returns 304 after a local deletion, mark the sample unresolved and perform one bounded ordinary GET without the stale condition. Never turn a missing body into an empty business result.

3. Change market or language in a separate test cell

Create a fresh record for each approved market-language combination. Start with an ordinary retrieval rather than recycling another cell's validator. Check a meaningful field such as fixture market code, localized label, or expected currency against the site's specification. Revalidate within each cell and compare results with its own baseline.

A rotated exit does not automatically mean new content, and the same exit does not guarantee identical content. Separate the chosen market from the observed exit and the actual returned variant. If two cells unexpectedly resolve to one cached record, investigate the client key and the origin's variation contract before blaming the residential route.

4. Keep failures and bandwidth evidence separate

If a 304 is paired with the wrong market or identity record, stop reuse and rebuild that cell after correcting its key. If an expected validator is absent, fall back to ordinary retrieval. If a response is a login, consent, or error page, do not promote it to the valid fixture solely because its status is 200. A timeout remains a failed validation attempt; it cannot extend the last successful validation time.

Count request attempts, validated reuses, full-body replacements, missing-copy recoveries, and measured transferred bytes separately. Compare matched workloads over the same interval with concurrency and retry limits held fixed. Fewer response-body bytes do not establish a particular billed reduction: inspect account usage and the applicable plan rather than extrapolating a price promise.

Where 98IP fits

Use the 98IP dynamic residential IP product page when the acceptance matrix needs selected residential market routes. Configure only parameters available in your account, then confirm the observed route before testing each variant. Conditional-response decisions belong to the endpoint and client; buying a route does not add validators or repair an incorrect local cache.

For a problem involving an incomplete new response rather than conditional reuse, continue with the response integrity test. That check complements this guide: first establish whether a usable representation exists, then decide whether this request is entitled to reuse it.

FAQ and release checklist

Can I create an ETag from my local hash? Keep a local hash for corruption detection, but send only the validator issued for the representation by the endpoint. A made-up validator is not evidence that the server recognizes your copy.

Should every 304 count as a new data sample? Record a validation observation and retain the existing data version. Distinguish its original retrieval time from its latest successful validation time in reports.

Before rollout: prove unchanged, changed, and missing-copy cases; keep regional and identity partitions distinct; replace body and metadata atomically; bound recovery requests; check valid business content; retain sanitized evidence; and compare actual usage before claiming savings.

Run these tests only on owned or explicitly authorized endpoints. Honor authentication, rate limits, privacy rules, and the site's cache restrictions. Do not share authenticated representations between users or use IP rotation to evade a refusal.