Opened 9 years ago

Closed 9 years ago

#12536 closed (invalid)

Issue with usage of @vary_on_cookie decorator with URLconf based cache_page usage

Reported by: Justin Owned by: nobody
Component: Core (Cache system) Version: 1.0
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


For several months, we have been caching views using the URLconf
method ( An entry from is below as an example:

url(r'^(?P<path>.*)/content/(?P<id>[-\w]+)/$$', cache_page(hierarchies.views.category_content_detail, CACHE_TIMEOUT),name='category_content_detail'),

Recently, we had a need to add variance of cache based on cookie value
to support some personalization features. After reading the django
docs, it seemed easy enough to add the @vary_on_cookie decorator to
appropriate views.

def category_content_detail(request, path, id):

What I've noticed, is that since adding this vary decorator, the page
is no longer caching, as seen by monitoring logs and seeing many
backend processes firing which normally do not fire when the page is

Any ideas on why I'd see this behavior? My browser is setting the
cookie value appropriately, as I've monitored in Firebug, but I'm just
not seeing any sort of caching taking place. Upon removing the
vary_on_cookie decorator, caching returns to normal.

What I have noticed in testing is this. If I go back to a pure per-view cache setup:

@cache_page(60 * 15)
def category_content_detail(request, path, id):

Is there a way to use vary_on_cookie with the URLconf like setup? I
like the flexibility of the URLConf method and but also need the vary

I've also attempted to use the patch_vary_headers function in the views per the docs, with the same results (no caching taking place).


Change History (1)

comment:1 Changed 9 years ago by Russell Keith-Magee

Resolution: invalid
Status: newclosed
def my_view(request...)

is not the same as

def my_view(request...)

You mention that the first approach works. However, your URLConf view is effectively doing the second.

Note: See TracTickets for help on using tickets.
Back to Top