Incorrect Behavior of ConditionalGetMiddleware

[Mark Lavin]

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

[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.

[Mark Lavin]

Added PR ​https://github.com/django/django/pull/2555

[Tim Graham <timograham@…>]

In 79956d06946c881cb71958f27a12f62b9cab8de5:

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