Opened 6 years ago

Closed 6 years ago

#26771 closed Bug (duplicate)

ETags broken when using GZipMiddleware

Reported by: Kevin Christopher Henry Owned by: nobody
Component: HTTP handling Version: dev
Severity: Normal Keywords:
Cc: k@… Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


When GZipMiddleware compresses the response, it changes the ETag by appending ;gzip. That's a good thing, and compliant with the specification, since you shouldn't use the same strong ETag for two different sequences of bytes.

The problem comes when the request tries to do a conditional GET using that ETag (via the If-None-Match header). That ETag will be compared to the ETag without the ;gzip suffix and will never match. (This is true whether using the ConditionalGetMiddleware or the condition decorator). So no one doing gzip compression of their responses is getting any use out of their ETags.

The most straightforward solution, I think, and one that's a good match for the layered nature of middleware, would be to strip out the ;gzip in the process_request phase of GZipMiddleware.

Change History (2)

comment:1 Changed 6 years ago by Tim Graham

Duplicate of #16035/#19705?

comment:2 Changed 6 years ago by Kevin Christopher Henry

Cc: k@… added
Resolution: duplicate
Status: newclosed

Yes, it's a duplicate of #16035, though unfortunately this specific problem seems to have been forgotten in the merge with #19705. I've put my thoughts about the various ETag issues there.

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