Opened 8 years ago
Closed 8 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 |
Description
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 by , 8 years ago
comment:2 by , 8 years ago
Cc: | added |
---|---|
Resolution: | → duplicate |
Status: | new → closed |
Duplicate of #16035/#19705?