Opened 5 years ago

Closed 4 years ago

#22440 closed Bug (fixed)

Incorrect Behavior of ConditionalGetMiddleware

Reported by: Mark Lavin Owned by: Mark Lavin
Component: HTTP handling Version: master
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


There is an edge case where the ConditionalGetMiddleware violates RFC 2616 in particular

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 Changed 5 years ago by Mark Lavin

Same check for the status code is needed for the If-Modified-Since:

If the request would normally result in anything other than a 200 (OK) status, or if the passed If-Modified-Since date is invalid, the response is exactly the same as for a normal GET. A date which is later than the server's current time is invalid.

comment:2 Changed 5 years ago by Mark Lavin

Has patch: set

comment:3 Changed 5 years ago by Julien Phalip

Triage Stage: UnreviewedAccepted

comment:4 Changed 4 years ago by Tim Graham

Type: UncategorizedBug

comment:5 Changed 4 years ago by Tim Graham <timograham@…>

Resolution: fixed
Status: newclosed

In 79956d06946c881cb71958f27a12f62b9cab8de5:

Fixed #22440 -- Updated ConditionalGetMiddleware to comply with RFC 2616.

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