Conditional View Processing in Django: ETags, Last-Modified, and the Condition Decorator

Introduction

HTTP clients often send headers that indicate which version of a resource they already have. This allows servers to avoid sending full responses when nothing has changed. Django supports this through ETag and Last-Modified headers, which can be set manually or automatically via middleware.

When a client sends headers like If-Modified-Since or If-None-Match, Django can return a 304 Not Modified response instead of regenerating the full page. If the resource has changed unexpectedly, Django may return 412 Precondition Failed.

The Condition Decorator

For fine-grained control, Django provides the condition() decorator. It accepts two optional functions:

• etag_func: returns a string ETag
• last_modified_func: returns a datetime object

These functions receive the same arguments as the view itself and allow Django to “bail out early” if the resource has not changed.

Signature

condition(etag_func=None, last_modified_func=None)

Example

Suppose you have a blog system where the front page only changes when a new entry is published:

def latest_entry(request, blog_id):
    return Entry.objects.filter(blog=blog_id).latest("published").published

You can use this function to enable conditional responses:

from django.views.decorators.http import condition

@condition(last_modified_func=latest_entry)
def front_page(request, blog_id):
    ...

Decorator Ordering Warning

Decorators like vary_on_cookie(), vary_on_headers(), and cache_control() must appear above condition(). Conditional responses skip decorators below them, so required headers must be added first.

Shortcuts: etag() and last_modified()

If you only need one validator, Django provides simpler decorators:

etag(etag_func)
last_modified(last_modified_func)

Example

@last_modified(latest_entry)
def front_page(request, blog_id):
    ...

Or equivalently:

front_page = last_modified(latest_entry)(front_page)

Do NOT chain etag() and last_modified()

This is incorrect:

@etag(etag_func)
@last_modified(last_modified_func)
def my_view(request):
    ...

Each decorator works independently and may produce incorrect results. Use condition() when both validators are needed.

Using Conditional Processing with Unsafe Methods

Conditional validation is not limited to GET and HEAD. It also works with POST, PUT, and DELETE to prevent overwriting stale data.

Example Workflow

1. Client GETs /foo/ and receives ETag "abcd1234".
2. Client sends PUT with If-Match: "abcd1234".
3. Server recomputes ETag.
4. If ETag changed → return 412 Precondition Failed.
5. Client fetches updated version before retrying.

This ensures safe concurrent updates.

Validator Headers for Unsafe Methods

The condition() decorator only sets ETag and Last-Modified for safe methods (GET, HEAD). If you want them on PUT or POST responses, set them manually in the view.

Comparison with ConditionalGetMiddleware

Django also provides ConditionalGetMiddleware, which handles conditional GET globally. However, it has limitations:

• Applies to all views
• Does not prevent expensive view processing
• Only works for GET requests

Use condition() when:

• You can compute ETag or last-modified quickly
• Your view is expensive to generate
• You need conditional logic for POST/PUT/DELETE

Use middleware when:

• Your views are already fast
• You only need conditional GET

Conclusion

Conditional view processing in Django provides powerful tools for optimizing performance and ensuring safe updates. With ETag and Last-Modified validators, the condition decorator, and proper use of HTTP precondition headers, you can significantly reduce unnecessary computation and bandwidth usage while maintaining data integrity.