Opened 12 years ago

Last modified 8 years ago

#19705 closed Bug

CommonMiddleware handles If-None-Match incorrectly — at Version 1

Reported by: Aymeric Augustin Owned by: nobody
Component: HTTP handling Version: dev
Severity: Normal Keywords:
Cc: hirokiky@…, real.human@…, k@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Aymeric Augustin)

Two middleware check ETags for unmodified responses: CommonMiddleware and ConditionalGetMiddleware and they do it inconsistently.

If the response's ETag matches the request's If-None-Match:

  • ConditionalGetMiddleware changes the response code to 304, preserving all headers; the content gets removed later on
  • CommonMiddleware creates a new HttpResponseNotModified without content and simply restores the cookies.

As a consequence, CommonMiddleware returns a response without ETag, which is wrong. I detected this with RedBot on a Django site I run. Any site with USE_ETAGS = True has this problem.

In general, wiping headers sounds like a bad idea. A 304 is supposed to have the same headers as the 200. (Well, the RFC is more complicated, but I think it's the general idea. Future versions of HTTP will likely require the Content-Length not to be 0.)


I believe that CommonMiddleware should simply generate the ETag and not handle conditional content removal; that's the job of ConditionalGetMiddleware.

For example, if one is using GzipMiddleware, the correct response chain is:

  • CommonMiddleware computes the ETag,
  • GzipMiddleware compresses the content and modifies the ETag,
  • ConditionalGetMiddleware uses the modified ETag to decide if the response was modified or not.

This is a good reason to keep "ETag generation" and "Etag checking" concerns separate. The same argument applies to any middleware that sets or modifies ETags.

Unfortunately, CommonMiddleware is documented to "take care of sending Not Modified responses, if appropriate", so this would be a backwards incompatible change.

Change History (1)

comment:1 by Aymeric Augustin, 12 years ago

Description: modified (diff)
Summary: CommonMiddleware handles If-Modified-Since incorrectlyCommonMiddleware handles If-None-Match incorrectly
Triage Stage: UnreviewedAccepted
Note: See TracTickets for help on using tickets.
Back to Top