412 Through a Proxy? Test If-Match Before Repeating an Update

A PUT request through a proxy returns 412 Precondition Failed. Removing the condition or immediately repeating an old payload may make an update appear successful while overwriting someone else's newer edit. First determine which version the request was allowed to replace.

This guide proposes a small conditional-update test on an owned or explicitly authorized API. It separates expected version conflict, request delivery and safe recovery. It does not claim the target supports If-Match unless its documentation confirms that contract, and it reports no executed test or proxy performance result.

1. Confirm the update contract

Identify the exact resource URL, representation, authentication context, supported update method and validator policy. Use a dedicated staging resource containing harmless marker fields. Disable downstream email, payment or other business actions for this fixture.

MDN describes If-Match as a conditional request using strong ETag comparison; a weak tag marked W/ cannot satisfy that comparison. Preserve the validator exactly as issued, including quotes. Do not manufacture a strong validator by deleting W/.

A documented conditional update can reject a stale version with 412. The status is not the same as proxy authentication failure or an unknown transport timeout. If the API uses a different concurrency protocol, test that protocol instead of adding an unsupported header and assuming protection.

2. Read and bind the original version

1. Retrieve the dedicated resource through an approved route and verify its resource ID and marker.
2. Record the response's validator and a sanitized snapshot of the fields needed for the edit.
3. Bind the proposed edit to that resource URL, representation and validator in one test record.
4. Keep the target identity and relevant request settings fixed; a validator from another account or resource is not interchangeable.
5. Prepare distinct harmless edits A and B from the same initial snapshot.

Do not infer a current validator from an old screenshot or cached export. Record when and from which response it was obtained. If only weak validators or no usable validator are supplied, mark this fixture unsupported under its chosen contract and ask the target owner for the documented alternative.

3. Demonstrate rejection with a deterministic sequence

Submit edit A using the original validator and require the target's documented success response. Read the resource back and verify A's intended marker and the updated version. The fixture must actually change the resource; a no-op edit is unsuitable for testing version advancement.

Now submit edit B using the old validator. Under this fixture's contract, require 412 and verify by reading back that A's saved state was not replaced by B. The rejection status alone is insufficient if the server nevertheless changed the resource.

Use server-side case records to confirm the If-Match value, method, resource ID and payload marker received. A header printed in a client log is evidence of intent, not proof of what the destination evaluated.

4. Check the compare-and-update boundary

If concurrent writers are in scope, use an owned staging gate to release two different edits with the same original validator. For this version-changing fixture, accept one update and reject the stale contender, then verify the final resource is the winner's complete expected state.

The version check and mutation must follow the API's atomic concurrency contract. If both competing edits are accepted from the same old version, a sequential test may pass while lost-update protection still fails under contention. Do not blame proxy timing without receiver and final-state evidence.

Set a small concurrency level and a fixed deadline. These are correctness fixtures, not load tests. If the controlled release condition is not achieved, record the concurrent case as incomplete rather than claiming a successful race test.

5. Recover by reviewing state, not just refreshing a tag

After a confirmed conflict, read the current resource and compare it with the original snapshot and proposed edit. Preserve the other writer's changes. Merge only according to explicit business rules, or present the conflict for a human decision where those rules are insufficient.

Blindly fetching the newest ETag and attaching it to the unchanged stale replacement body can overwrite the very change that 412 protected. A new conditional attempt must represent a reviewed update based on the new state. It can conflict again; bound the number of attempts.

If an update times out with an unknown outcome, use the destination's receipt or readback rules before another write. A later 412 may mean the version advanced, but does not identify who changed it or prove the earlier request succeeded. Correlate the actual intended change and authorized server evidence.

6. Compare proxy delivery with the same contract

Run independent, reset staging fixtures on an approved baseline and proxy route, keeping client version, resource contract and payload generation fixed. Do not reuse a resource already modified by the baseline without resetting it and obtaining its new validator.

The 98IP dynamic residential IP page is relevant to selecting a product for authorized API-route checks. Verify current connection methods and account options through the API configuration page. Proxy access does not define the target's atomic update behavior or replace its concurrency rules.

• Current validator and real change: documented success plus correct readback.
• Stale validator after A commits: 412 plus no overwrite.
• Weak or unsupported validator: explicit unsupported or rejection outcome, without stripping its marker.
• Two controlled writers: the declared atomic guard prevents both stale replacements from succeeding.
• Reviewed recovery: other changes survive the new conditional edit.
• Unknown response: readback or receipt is used before considering another write.

These cases are proposed, not measured outcomes. Record case ID, route label, client, resource ID, validator lineage, received condition, response, final marker and first mismatch. Redact secrets and customer data; retain only the minimal synthetic evidence needed to distinguish conflict from delivery failure.

FAQ and acceptance checklist

Does 412 mean the proxy is broken? No. A stale-version fixture should be rejected under its documented contract.

Can removing If-Match fix the problem? It removes the tested protection and changes the operation; it is not a passing recovery.

• The API actually documents the chosen condition and update method.
• Validators stay bound to the correct resource and representation.
• Rejection is checked against the final stored state.
• Concurrent correctness is verified separately where required.
• Recovery reviews changes instead of blindly replacing a validator.
• Only authorized staging writes and harmless fixtures are used, with bounded attempts and no unsupported reliability claims.