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 Russell Keith-Magee, 15 years ago

Triage Stage: UnreviewedAccepted

comment:2 by niwi@…, 14 years ago

Easy pickings: unset
Severity: Normal
Type: Bug

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

sqlite> select cache_key from testcache;
:1:views.decorators.cache.cache_header..0d315d531c1d665a169d1c5df90c50eb.es
:1:views.decorators.cache.cache_page..GET.0d315d531c1d665a169d1c5df90c50eb.cc775e21f18c02dc9fb51010878bc022.es
sqlite> delete from testcache;

Database select with DEBUG=False

sqlite> select cache_key from testcache;
:1:views.decorators.cache.cache_header..0d315d531c1d665a169d1c5df90c50eb.es
:1:views.decorators.cache.cache_page..GET.0d315d531c1d665a169d1c5df90c50eb.cc775e21f18c02dc9fb51010878bc022.es
:1:views.decorators.cache.cache_page..GET.0d315d531c1d665a169d1c5df90c50eb.52984fbac17d6264bc671574cc7f150b.es
:1:views.decorators.cache.cache_page..GET.0d315d531c1d665a169d1c5df90c50eb.6e721d5f3f637978913099b512dab876.es
:1:views.decorators.cache.cache_page..GET.0d315d531c1d665a169d1c5df90c50eb.c76a223f2cb4df2a5b27cc2acd7b23ff.es
:1:views.decorators.cache.cache_page..GET.0d315d531c1d665a169d1c5df90c50eb.53da06fed77acf000071813587833708.es
:1:views.decorators.cache.cache_page..GET.0d315d531c1d665a169d1c5df90c50eb.4d44279ce9d42c1cdc41ff9fba74bfa1.es
:1:views.decorators.cache.cache_page..GET.0d315d531c1d665a169d1c5df90c50eb.5068bbfa80f990c0fca3a42173d203c8.es
:1:views.decorators.cache.cache_page..GET.0d315d531c1d665a169d1c5df90c50eb.662c59ccdd121bfe051841e975b46580.es
[...]

Class View used for this test.

class CacheMixIn(object):
    """ Class for generic cache decorator. """
    @method_decorator(cache_page(60*2))
    @method_decorator(vary_on_headers('User-Agent', 'Cookie'))
    def dispatch(self, *args, **kwargs):
        return super(CacheMixIn, self).dispatch(*args, **kwargs)


class ObjectListMixIn(ListView):
    """ Class for generic settings for all object list. """
    allow_empty = True
    paginate_by = 20


class PostsView(CacheMixIn, ObjectListMixIn):
    queryset = Post.objects.exclude(public=False).order_by('-created_date')

comment:3 by Aymeric Augustin, 13 years ago

UI/UX: unset

Change UI/UX from NULL to False.

comment:4 by Claude Paroz, 10 years ago

Resolution: needsinfo
Status: newclosed

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.

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