ETags broken when using GZipMiddleware

[Kevin Christopher Henry]

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.

[Tim Graham]

Duplicate of #16035/#19705?

[Kevin Christopher Henry]

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.