Opened 15 years ago
Closed 10 years ago
#11997 closed Bug (needsinfo)
cache_control returns 200 OK response even page has not been changed.
Reported by: | Jani Tiainen | Owned by: | nobody |
---|---|---|---|
Component: | Core (Cache system) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Provided code:
@cache_control(must_revalidate=True) @cache_page(60 * 60) def myview(request) return HttpResponse('test')
Symptoms:
Returns always 200 OK response and complete cached content. Modified since and modified dates and ETags in request and response headers do match.
Correct behavior:
Return value 304 Not Modified if cache conditions are met and do not fetch data from cache nor execute view.
Change History (4)
comment:1 by , 15 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 14 years ago
Easy pickings: | unset |
---|---|
Severity: | → Normal |
Type: | → Bug |
comment:4 by , 10 years ago
Resolution: | → needsinfo |
---|---|
Status: | new → closed |
I think that the response of the server is strongly dependent of installed middlewares. Typically, the 304 response you expect would be produced by the ConditionalGetMiddleware
.
If you still suffer from this issue, the best step forward would be to setup a minimal project to reproduce the issue, so as we can debug cache and middleware interactions.
I passed something similar, using Generic Class Views.
With DEBUG=True works ok (Returns 304), but with DEBUG=False always returns 200 (And it creates a new cache entry for each request)
Database select with DEBUG=True
Database select with DEBUG=False
Class View used for this test.