ConditionalGetMiddleware returns 304 if ETag is the same but Last-Modified has changed.

[Flavio Curella]

ConditionalGetMiddleware in combination with apache x-sendfile (django-sendfile) doesn't work properly.

Each response gets a ETag generated based on response.content which is an empty string in the case of a x-sendfile response, so each time the file is accessed, the ETag generated by ConditionalGetMiddleware is the same. Regardless of the changed file/changed mtime. In get_conditional_response() the ETag (which is always the same hash of empty string) is checked first and returns a 304 because it ignores Last-Modified time. Django shouldn't return 304 if ETag is the same but Last-Modified has changed.

Related with #29241.

[Mariusz Felisiak]

Thanks for the ticket (please try to add more descriptive description in the future).

[Dart]

Hello! Please, check my pull request. I dont know is it django "right" way, but its works. So my solution was to check x-sendfile header and if it exists ignore etag comparison, because in this situation etag does not matter.
​https://github.com/django/django/pull/11878

[Dart]

​https://github.com/django/django/pull/11879
Fix small issues

[Mariusz Felisiak]

Thanks for this patch, however I don't think that it is a right solution. This issue is not about nginx, it is about ConditionalGetMiddleware and how it behaves with the same Etag and changed Last-Modified time (see ​https://tools.ietf.org/html/rfc7232).

[Claude Paroz]

One possible solution would be to not generate an Etag for empty content. I didn't find documentation about that specific case, but for me, it does not make much sense to cache (return 304) empty responses.

As for the precedence between Etag and Last modified conditions, I think Django is respecting the specs.

[Dart]

So as i see there two posible solutions:

• remove generation etag from middleware if empty content exists

or

• add one more attributes for generation etag

No matter from rfc-7232:

An origin server SHOULD send an ETag for any selected representation
for which detection of changes can be reasonably and consistently
determined, since the entity-tag's use in conditional requests and
evaluating cache freshness ([RFC7234]) can result in a substantial
reduction of HTTP network traffic and can be a significant factor in
improving service scalability and reliability.

Or we can do nothing and rely on customer understanding

[Dart]

​https://github.com/django/django/pull/11891
Add checking response content before generating Etag.

[Mariusz Felisiak <felisiak.mariusz@…>]

In ee6b1718:

Fixed #30812 -- Made ConditionalGetMiddleware set ETag only for responses with non-empty content.