What is a conditional HTTP request?
Quick answer
A conditional HTTP request asks a server to process a request only if a stated condition about a resource is met. The condition uses a validator, such as an ETag or Last-Modified date. For a GET request, this can let the server indicate that cached content is unchanged; for an update, it can help prevent overwriting a resource that changed since it was read. The effect depends on server support and the condition used. [S1]
The question, the details, the next step.
What does “conditional” mean here? Is it just another name for ordinary caching?
It means the server’s processing depends on a precondition in the request. That condition compares the resource with a validator, such as an ETag or a Last-Modified date. [S1] Caching is one use, but not the only one: a condition can also help protect an update from overwriting changes made since the client last read the resource.
A useful distinction is the goal: with a GET request, you may want to avoid receiving the same content again; with an update, you may want the server to proceed only if the resource is still in the expected state.
How does the cache-validation case work?
A client can retain a response and later make a conditional GET using a validator associated with that resource. If the content has not changed, the server can respond with 304 Not Modified, rather than retransmitting unchanged content. [S1]
For example, suppose a client previously received a document and an ETag. On a later request, it asks whether the resource still matches that validator. If so, it can continue using its stored copy. This describes the purpose, not a guarantee: the server must support the relevant condition, and the result depends on the condition used. [S1]
What changes when I’m sending an update instead of checking a cached GET?
For an update, the concern is avoiding a write based on an outdated copy. A client can use a condition such as If-Match or If-Unmodified-Since to ask the server to apply the update only if the resource has not changed since it was read. If the precondition fails, the server can return 412 Precondition Failed. [S1]
Worked example, with placeholders: you read [resource] and receive validator [ETag]; before sending your update, include a condition using that validator. If another change means it no longer matches, the precondition can fail instead of silently replacing the newer version. This is a conflict signal to handle, not a promise that every server enforces the condition. [S1]
How should I choose which kind to use, and what should I check when testing?
Start with the outcome you need. If you want to check whether a GET response is still current, use a cache-validation condition. If you want an update to depend on the resource remaining as last observed, use an update precondition. The relevant validators and response behavior vary with the condition, and practical effects depend on server support. [S1]
A small test plan can use a resource you control: make a conditional GET with a validator, then separately try an update condition after changing the resource. Observe whether the server returns a not-modified response or a failed-precondition response where applicable. These mechanisms and example outcomes do not establish that a particular API supports them, how it generates validators, or what its application does after a failure. [S1]
A practical checklist
Decide whether your goal is to validate a cached GET response or guard an update.
Check whether the server supplies or accepts a validator for the resource.
Choose a condition that matches the operation; do not treat cache validation and update protection as interchangeable.
For a controlled test, record the request condition and the server’s response when the resource is unchanged and when it has changed.
Plan how your client will respond if an update precondition fails, rather than assuming the server applied the update.
A few more useful answers
Does a `304 Not Modified` response mean the server sent a fresh copy?
No. In the described GET case, it indicates that the content is unchanged, avoiding retransmission; the client can use its stored copy. [S1]
Does using an update condition guarantee that no changes can be overwritten?
No universal guarantee follows from the mechanism alone. Its practical effect depends on server support and the condition used. [S1]
What does `412 Precondition Failed` mean in this context?
It can indicate that an update’s precondition failed, such as when the resource changed since it was read. [S1]
Sources
References used for this guide.
- [S1] HTTP conditional requests — MDN Web Docs developer.mozilla.org · Checked