Cybersecurity glossary
What is a Conditional Request?
Learn how conditional HTTP requests use validators and preconditions to avoid unnecessary transfers, power cache revalidation, and implement safe concurrent updates with If-Match and 412 responses.
Definition
A conditional request is an HTTP request that includes preconditions in headers such as If-None-Match, If-Match, If-Modified-Since, or If-Unmodified-Since, so the server can return a short 304 or 412 response instead of a full body when the resource state does not meet the condition.
Why conditional requests matter
Without conditionals, every doubt about freshness becomes a full download. Conditional requests let clients and caches ask precise questions: “Is this ETag still current?” or “Has this resource changed since Tuesday?” The server answers with a few hundred bytes instead of megabytes.
Beyond bandwidth, conditionals underpin safe concurrent edits. APIs use If-Match to ensure two writers do not silently overwrite each other—a pattern security and reliability teams should recognize alongside classic cache validation.
How conditional requests work
The client includes a precondition header derived from a prior response. The server evaluates it against the current resource state and either short-circuits with 304 or 412, or proceeds with a normal 200/204 and updated validators.
Client holds prior metadata
A previous response supplied ETag, Last-Modified, or both.
Precondition header attached
If-None-Match or related headers express the assumed state.
Server compares state
Current entity tags or dates are evaluated against the precondition.
Short-circuit or proceed
Matching validation preconditions yield 304; failed write preconditions yield 412.
Validators updated on change
Full responses include new ETag/Last-Modified for the next round trip.
Common precondition headers
If-None-Match
Used with GET/HEAD for cache validation; matching ETag returns 304.
If-Match
Guards PUT/PATCH/DELETE; mismatch returns 412 Precondition Failed.
If-Modified-Since
Time-based validation for GET; origin returns 304 if not modified since the date.
If-Unmodified-Since
Write guard using modification time instead of ETag.
If-Range
Ensures partial content requests align with the current representation.
ETag on responses
Origins should emit consistent strong or weak tags validators can reference.
Conditional patterns in practice
| Use case | Typical header | Typical outcome |
|---|---|---|
| Browser cache revalidation | If-None-Match: "abc123" | 304 with empty body; cache refreshes metadata |
| API optimistic locking | If-Match: "rev-7" | 412 if another writer incremented the revision |
| CDN origin check | If-Modified-Since | 304 saves origin egress on unchanged assets |
| Resume large download | If-Range + Range | 200 with range or full 200 if representation changed |
| Accidental missing validator | (none) | Full 200 every time; caching benefits lost |
Implementation checklist
- Return ETag or Last-Modified on cacheable GET responses that can change without URL changes.
- Honor If-None-Match with 304 only when the resource is genuinely unchanged.
- Require If-Match on state-changing APIs where lost updates would be security-relevant.
- Use strong ETags when byte-identical responses matter; weak ETags when semantics matter.
- Ensure authorization is evaluated before 304; never leak existence via validators alone.
- Test intermediaries: some proxies mishandle 304 bodies or strip validators.
- Document validator stability across deploys; changing ETag algorithms invalidates caches abruptly.
- Pair conditional caching with correct Vary when multiple representations exist.
Limits and pitfalls
A 304 omits the body but still confirms the client’s validator was valid. For highly sensitive resources, even revealing “unchanged” may be undesirable—those responses should not be cacheable cross-user.
Weak ETags and one-second Last-Modified granularity can produce false matches. Conversely, regenerating ETags on every response—even when bytes are identical—destroys validation efficiency.
If-Match: * and sloppy handler implementations have historically enabled unexpected writes. Treat precondition evaluation as security-sensitive server logic, not a framework afterthought.
The practical takeaway
Conditional Request headers turn HTTP into a conversation about resource state instead of blind full transfers. Caches use them to revalidate; APIs use them to prevent clobbering updates.
Emit trustworthy validators, implement precondition checks consistently on the origin, and remember that efficient 304 responses still require correct authorization and cache keying upstream.
Related security terms
Cache Revalidation
The caching workflow that relies heavily on conditional GET requests.
Cache-Control
Directives that cause caches to issue conditional requests before reuse.
Cache Key
Determines which stored representation validators belong to.
HTTPS
Encrypts conditional traffic so validators cannot be trivially tampered with.
Frequently asked questions
What is a conditional request in simple terms?
The client tells the server what it already knows about a resource—like an ETag or date—and asks the server to skip sending the body if nothing changed.
Which headers make a request conditional?
Common precondition headers include If-None-Match, If-Match, If-Modified-Since, and If-Unmodified-Since. Range requests use If-Range in a related pattern.
What is the difference between If-None-Match and If-Match?
If-None-Match is used for cache validation and safe reads: match means return 304. If-Match is used before writes: the server applies the change only if the ETag still matches, otherwise 412.
When do browsers send conditional requests automatically?
During cache revalidation, back-forward cache restores, and some navigations where a stored response has validators and freshness rules require checking the origin.
Can conditional requests improve security?
They reduce unnecessary data exposure and enable optimistic concurrency control on APIs. They do not replace authorization; a 304 still reveals that the client had a valid prior representation.
What status codes relate to conditional requests?
304 Not Modified means the precondition for a GET/HEAD succeeded and the body is omitted. 412 Precondition Failed means a state-changing request failed its If-Match or If-Unmodified-Since check.
References
Explore authoritative guidance and frameworks related to conditional request.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.