If-Unmodified-Since

Technique Definition

If-Unmodified-Since makes a request conditional on the selected representation not having been modified after the supplied date. Under Existence Oracle analysis, it is the date-based precondition analogue to If-Match.

Primary Headers / Methods

Request Header

• If-Unmodified-Since

Representation Metadata It Relies On

• Last-Modified

Primary Method Context

• PUT
• PATCH
• DELETE
• Other methods where preventing changes to a newer representation matters

Secondary Method Context

• Can also matter with other representation-sensitive requests, but its clearest use here is state-protection precondition evaluation.

Can Elicit

Primary Differential

• 412 vs 404

Secondary / Adjacent Outcomes

• 2xx vs 404 when the target exists and has not been modified after the supplied date, depending on the method and whether the request succeeds
• Occasionally 2xx instead of 412 if the RFC-permitted already-applied branch is used

Stage Role

Under this taxonomy, If-Unmodified-Since is the date-based trigger for the 412 vs 404 differential.

Best Use

If-Unmodified-Since is best used when the goal is to test date-based precondition evaluation rather than ETag-based precondition evaluation.

It is most useful when:

• ETag is unavailable or unstable
• Last-Modified is available and meaningful
• you want to confirm that date-based state-protection logic itself creates the existence signal

Why It Works as an Existence Trigger

A false If-Unmodified-Since evaluation shows that the server got far enough to locate the selected representation and compare its last modification date against the supplied condition. A nonexistent target does not reach that comparison outcome and instead bottoms out at 404 Not Found.

Method Applicability

PUT

• Primary method context.
• Useful when updates should fail if the server's representation is newer than the client expects.

PATCH

• Primary method context.
• Useful for partial modification under optimistic concurrency assumptions.

DELETE

• Primary method context.
• Useful when deletion should fail if the representation has changed since the client's last known state.

Other Methods

• Possible in broader HTTP semantics, but less central to the oracle classification here.
• This page stays focused on the 412 vs 404 precondition branch rather than generalized conditional request behavior.

Trigger Strength / Normative Level

Strong Precondition Core, Weaker Response-Code Branch

When an origin server evaluates an If-Unmodified-Since condition and it evaluates false:

• the server MUST NOT perform the requested method
• the server MAY indicate failure with 412 Precondition Failed

Practical Result

This gives If-Unmodified-Since a real RFC-defined precondition basis, but the emitted 412 is not as rigidly mandated as the 304 / 412 branching for If-None-Match. That matters for portability.

Portability Notes

• This technique is weaker than If-Match because it depends on date comparison rather than ETag comparison.
• Date validators are coarser than entity tags; timestamp granularity can make borderline cases ambiguous.
• Portability depends on the server exposing and honoring meaningful Last-Modified semantics.
• Rapid same-second modifications, synthetic timestamps, or missing / coarse last-modified handling can reduce reliability.
• Caches and intermediaries can ignore this header because it is not applicable to a stored response; the oracle value here is origin-side precondition evaluation.

Detection Notes

1. Establish a known-existing target and a known-nonexistent target.
2. Use a method context where If-Unmodified-Since meaningfully applies, such as PUT, PATCH, or DELETE.
3. Add only one manipulator: an If-Unmodified-Since date designed to evaluate false for the existing target.
4. Compare outcomes.
5. A 412 on the existing target and 404 on the nonexistent target is the cleanest oracle confirmation for this technique.

Relationship to Other Techniques

Versus If-Match

• If-Match is the stronger ETag-based precondition technique.
• If-Unmodified-Since is the weaker, date-based analogue.

Versus If-Modified-Since

• If-Modified-Since is date-based validator retrieval.
• If-Unmodified-Since is date-based state-protection / precondition evaluation.

Scope & Limitations

• It does not prove that a shared cache is present.
• It does not prove that a prior response was stored.
• It does not prove anything about freshness lifetime, cache keying, or cache hits.
• It only proves that RFC-defined date-based precondition evaluation reached an existing current representation.