#13285 closed Bug (fixed)
Generic views call populate_xheaders, which breaks caching
Reported by: | Carl Meyer | Owned by: | Łukasz Langa |
---|---|---|---|
Component: | Core (Cache system) | Version: | 1.1 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Many of the Django generic views (as well as the flatpage view) call django.core.xheaders.populate_xheaders on the response. Populate_xheaders checks request.user, in order to include xheaders if the logged-in user is a staff member. Checking request.user triggers session access, which causes SessionMiddleware to add Vary: Cookie to the response, which makes caching much less efficient.
There should be some way to turn off populate_xheaders in production (or at least turn off the user-is-staff check), so efficient caching can be achieved.
Change History (14)
comment:1 by , 15 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
comment:2 by , 15 years ago
Resolution: | duplicate |
---|---|
Status: | closed → reopened |
Triage Stage: | Unreviewed → Accepted |
Apologies - I got myself confused here. Original reporter was correct - the issue here is that populate_xheaders is a debugging tool that breaks caching.
comment:3 by , 14 years ago
The function-based generic views are now deprecated, and the class-based views that replaced them do not call populate_xheaders. So the only remaining non-deprecated view in the Django source tree that calls populate_xheaders is the flatpage view.
My take at this point is that the populate_xheaders function itself is a) of marginal usefulness, since these sorts of debugging headers can easily be added without a generic function for it, b) now barely used within Django, c) breaks caching as written, and d) completely undocumented. So, barring major objections, I think it should just be removed from Django entirely. Since it's undocumented I don't think a deprecation path is strictly needed, but to err on the side of caution it could be deprecated along the same timeline as the function-based generic views, since they all call it.
comment:4 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → Bug |
comment:7 by , 12 years ago
Status: | reopened → new |
---|
comment:8 by , 12 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:9 by , 12 years ago
Owner: | changed from | to
---|
comment:10 by , 12 years ago
Two years later, it's probably time to remove it outright (and, since we're nice people, document it as a backwards incompatible change).
comment:11 by , 12 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
Łukasz will salvage the test and re-add them in another PR moving XViewMiddleware to d.c.admindocs, as it's only used by admindocs and not obviously useful otherwise.
comment:13 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I'm going to close this as a dupe of #13283; I know the presentation is different, but the root cause is the same - we need to be able to determine the login/access status of the current user without marking the session as dirty.