Opened 15 years ago
Closed 15 years ago
#12263 closed (invalid)
Mixed concerns between application and http caching
| Reported by: | Seb Bacon | Owned by: | nobody |
|---|---|---|---|
| Component: | Core (Cache system) | Version: | 1.1 |
| Severity: | Keywords: | etag http headers last-modified | |
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
I've found the treatment of HTTP cache headers in Django counterintuitive. I'm not sure if the code or the documentation needs fixing, so this is more a discussion point than a bug.
The cache middleware (in {{django.middleware.cache}} is for caching objects in memory. As a side-effect, it also sets ETag and Last-Modified dates.
1) I view this as a bug, as it's mixing two concerns -- application-level caching and HTTP caching. It certainly threw me when trying to debug some HTTP caching issues, as it interacts in unexpected ways with Django's explicit HTTP caching facilities such as the {{cache_control}}} decorator.
2) I'd rather HTTP caching was controlled completely separately, but if not, shouldn't this behaviour honour the USE_ETAGS setting that's used in {{django.middleware.CommonMiddleware}}?
3) Also, if it's considered that HTTP caching should be set at the same time as app caching, should we consider noting in the comments that the ConditionalGetMiddleware should be enabled if the server is to honour these headers?
I'm going to close this invalid. Trac isn't for raising discussion points - that's why we have a django-dev mailing list.