If-Modified-Since

Technique Definition

If-Modified-Since makes a GET or HEAD request conditional on the selected representation having been modified more recently than the date supplied in the field value. Under Existence Oracle analysis, it is the date-validator variant of validator elicitation.

Primary Headers / Methods

Request Header

• If-Modified-Since

Representation Metadata It Relies On

• Last-Modified

Primary Method Context

• GET
• HEAD

Method Limitation

• This technique is defined for GET and HEAD, not as a general cross-method precondition trigger.

Can Elicit

Primary Differential

• 304 vs 404

Secondary / Adjacent Outcomes

• 200 vs 404 when the representation has been modified more recently than the supplied date
• No primary 412 branch here; unlike broader precondition techniques, this header is not the clean route to 412 vs 404

Stage Role

Under this taxonomy, If-Modified-Since is a secondary validator-based trigger for 304 vs 404, weaker and less canonical than If-None-Match.

Best Use

If-Modified-Since is best used when the target exposes modification dates and the goal is to test date-based representation evaluation rather than ETag-based validator evaluation.

It is most useful when:

• ETag is absent or unstable
• the server still exposes a meaningful Last-Modified value
• you want to confirm that date-based conditional retrieval itself creates the existence signal

Why It Works as an Existence Trigger

If the selected representation has not been modified since the supplied date, the server can avoid transferring the representation and return 304 Not Modified. That outcome only makes sense if the server located an existing representation and evaluated its modification date. A nonexistent target instead bottoms out at 404 Not Found.

Method Applicability

GET

• Primary method for this technique.
• Cleanest date-based path to 304 vs 404.

HEAD

• Also primary.
• Same conditional logic, without transferring a response body.
• Important because it preserves the validator-oracle even when body-based differences are removed.

Other Methods

• Not the intended method context for this technique.
• This is one of the main reasons If-Modified-Since should stay clearly separate from broader precondition techniques.

Trigger Strength / Normative Level

Weaker Normative Core Than If-None-Match

When an origin server evaluates an If-Modified-Since condition and it evaluates false, the RFC uses SHOULD language for not performing the method and generating 304 Not Modified, rather than the stronger MUST language used for If-None-Match.

Practical Result

This still gives the technique a real RFC-defined basis, but the normative footing is weaker. That matters for portability: If-Modified-Since is a valid elicitation technique, but not the strongest canonical one.

Portability Notes

• This technique is weaker than If-None-Match because it depends on date comparison rather than entity-tag comparison.
• A recipient MUST ignore If-Modified-Since if the request also contains If-None-Match, so this technique should be tested in isolation.
• Portability depends on the server exposing and honoring meaningful Last-Modified information.
• Date validators are coarser than entity tags; timestamp granularity can make borderline cases ambiguous.
• Rapid same-second modifications, synthetic timestamps, or missing Last-Modified behavior can reduce reliability.

Detection Notes

1. Establish a known-existing target and a known-nonexistent target.
2. Send the same GET or HEAD request to both.
3. Add only one manipulator: If-Modified-Since with a date chosen to make an unmodified existing representation likely.
4. Compare outcomes.
5. A 304 on the existing target and 404 on the nonexistent target confirms the oracle for this technique.

Relationship to If-None-Match

If-Modified-Since should not be treated as an equal-strength twin of If-None-Match.

Key differences:

• If-None-Match is the stronger and more precise validator mechanism.
• If-Modified-Since is explicitly ignored when If-None-Match is also present.
• If-Modified-Since is therefore better treated as the fallback or secondary validator technique, not the primary one.

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 shows that date-based conditional evaluation reached an existing representation.