Opened 11 years ago
Closed 10 years ago
#22440 closed Bug (fixed)
Incorrect Behavior of ConditionalGetMiddleware
Reported by: | Mark Lavin | Owned by: | Mark Lavin |
---|---|---|---|
Component: | HTTP handling | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
There is an edge case where the ConditionalGetMiddleware
violates RFC 2616 in particular http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.26
If the request would, without the If-None-Match header field, result in anything other than a 2xx or 304 status, then the If-None-Match header MUST be ignored.
The middleware currently does not check the original response status code before the If-None-Match. This is correctly handled by the CommmonMiddleware
which has a similar check. This was pointed out in #12789 which tried to fix/address a related but seperate problem with how the ETag is actually generated. #17834 currently tracks problems with the generation of the ETag and this issue only tracks the problem with ConditionalGetMiddleware
using the ETag however it may have been generated
Change History (5)
comment:1 by , 11 years ago
comment:3 by , 11 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:4 by , 11 years ago
Type: | Uncategorized → Bug |
---|
comment:5 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Same check for the status code is needed for the If-Modified-Since: