@last_modified should ignore lack of etag method when USE_ETAGS is enabled.

[Chris Lamb]

Using @last_modified with settings.USE_ETAGS does not work as expected.

My goal is to avoid evaluating the view for a select handful of expensive pages based on the Last-Modified header, and globally fallback to saving bandwidth with USE_ETAGS.

However, if you enable USE_ETAGS and the @last_modified decorator, the view is still evaluated despite the last_modified_func being a match with If-Modified-Since. This is because the client is providing an ETag header (added because USE_ETAGS is enabled) and django.views.decorators.http.condition uses that etag along with the fact that we did did not provide an etag_func argument as a reason for not returning 304.

Patch attached that disables this particular part of the logic if settings.USE_ETAGS is enabled.

[Jannis Leidel]

I suppose this is related to r14885 and #14103, too.

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[Claude Paroz]

Refactoring, tests and docs

[Claude Paroz]

They were several issues related with condition decorator and the USE_ETAGS setting. Just run tests (especially conditional_processing) with USE_ETAGS=True in your settings to reveal errors.

My patch is solving these issues and also factorizes ETag generation at the response object level.

[Tim Graham]

Patch needs to be updated.

[Mariusz Felisiak]

Claude, Can you check is this still valid? settings.USE_ETAGS was removed in Django 2.1.

[Claude Paroz]

Wow, long time ago...

Looks like ​https://tools.ietf.org/html/rfc7232#section-6 specifies that Etag checking has precedence over the last modified header. I'd vote for won't fixing this. Chris, any renewed opinion?

[Mariusz Felisiak]

Claude, thanks! I agree let's close this ticket as wontfix.