HTTP 304 — Not Modified
HTTP 304 is the cache handshake payoff: the client sends validators (If-None-Match or If-Modified-Since), the server confirms nothing changed, and the body is omitted so only headers cross the wire.
When 304 shows up
- Browser cache revalidation of stylesheets, scripts and images.
- API clients with ETag-based conditional polling.
Mocking a 304 response
A response with this status can be faked end to end with a local mock rule — no backend changes needed. The configuration below mirrors the rule fields the ApiSimul editor uses (method, path, status, delay in milliseconds, response body):
{
"method": "GET",
"path": "/assets/app.js",
"status": 304,
"delay": 90,
"enabled": true,
"body": null
}Dynamic placeholders such as {{random.name}}, {{string.uuid}} or {{number.int 1 100}} can appear inside the body to vary each response, which keeps client-side list rendering and retry logic honest during development.
Frequently asked questions
What does HTTP 304 mean?
The cached copy is still fresh — use it. There is no body; the savings come from skipping the transfer entirely.
How can I test a 304 response without a real backend?
Define a mock rule with the method and path your client requests and set the status to 304. The example configuration above returns this response after the listed delay, so the client exercises its 304 handling exactly as it would against a live server.
Related status codes
Need the response in your own project? Spin up rules for any status with the ApiSimul mock server, or browse every status code page.