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 Mark Lavin, 11 years ago

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:3 by Julien Phalip, 11 years ago

Triage Stage: UnreviewedAccepted

comment:4 by Tim Graham, 11 years ago

Type: UncategorizedBug

comment:5 by Tim Graham <timograham@…>, 10 years ago

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