4

I was reading the django docs at http://docs.djangoproject.com/en/dev/topics/cache/?from=olddocs and I read the following line:

the cache middleware caches every page that doesn't have GET or POST parameters.

Does this mean that it won't cache pages that does have GET or POST parameters? If that's true, then it seems rather silly because a good portion of a website has some GET or POST parameters. Pagination, for example, is extremely common. Can anyone clarify this?

Thank you!

rabbid
  • 5,465
  • 7
  • 26
  • 37
  • 1
    I'm not sure I can answer your question. However, django is designed largely around the idea of avoiding passing parameters. You set up your urls in your urls.py which largely takes care of needing parameters. I have used parameters before (mainly for jqgrid since the plugin required them), but in this case that was for data that is changing and could differ greatly depending on params. So maybe that fact says having the cache wouldn't be much of a benefit? – wilbbe01 Apr 21 '11 at 00:43
  • Thanks for your comment. I see what you mean. However, even the Django Pagination tutorial uses a GET param. Check out [http://docs.djangoproject.com/en/1.3/topics/pagination/](http://docs.djangoproject.com/en/1.3/topics/pagination/). In this example Django uses the "page" GET parameter to serve the next/previous pages. I suppose I could trick Django unto having to parameters at all by only using regex in the URLs, but (1) Regex is a bitch, and (2) it just seems silly to completely disregard the HttpRequest object. Thanks! – rabbid Apr 21 '11 at 00:59
  • 1
    Yeah, I second your (1)....but when it is working it pays off. It's also fun looking back at your urls.py files and thinking about what it took to get there sometimes :). – wilbbe01 Apr 21 '11 at 01:04
  • @wibbe01: yeah definitely :) I might have found an answer [here](http://stackoverflow.com/questions/1590372/cache-a-django-view-that-has-url-parameters). Would be nice if someone could confirm it. I'll try it myself of course when I get the time. – rabbid Apr 21 '11 at 01:25

2 Answers2

1

The full url is used for cache keys. If we look at django/utils/cache.py there is get_cache_key which in turn calls _generate_cache_header_key. This gets the MD5 hash of the absolute url as shown with the active language too.

def _generate_cache_header_key(key_prefix, request):
    """Return a cache key for the header cache."""
    url = hashlib.md5(iri_to_uri(request.build_absolute_uri()).encode('ascii'))
    cache_key = 'views.decorators.cache.cache_header.%s.%s' % (
        key_prefix, url.hexdigest())
    return _i18n_cache_key_suffix(request, cache_key)
Boris Verkhovskiy
  • 14,854
  • 11
  • 100
  • 103
quiet_penguin
  • 808
  • 7
  • 18
1

Usually, if your application is designed right, there is no sense of caching pages with GET or POST.

Pages that use POST

POST data is usually a result with user interacting with forms. This means, that caching POST data might cache a request to delete a user, for example, or to add new record to a database. This wouldn't be good.

Pages that use GET

As for the GET parameters, they are meant to use for search pages, like those:

example.com/search?query=i%20might%20be%20never%20repeated%20again

There is no much sense of caching pages like that - they might be rendered only once in the lifetime.

Wrong way

However, you will get problems if you are using GET the wrong way:

example.com/viewprofile?userid=65

Parameters for views should be passed as part of url:

example.com/viewprofile/65
Community
  • 1
  • 1
Silver Light
  • 44,202
  • 36
  • 123
  • 164
  • 1
    Thanks for your reply. I ended up using the in-template caching to cache 3rd party stuff like Disqus, FB, Twitter. I think it's working OK so far. – rabbid Apr 21 '11 at 10:34