ConditionalGetMiddleware and x-sendfile

[TZanke]

We found a issue with ConditionalGetMiddleware in combination with apache x-sendfile (django-sendfile) and Django 1.11

In Django 1.10 we just use Last-Modified, which works fine. Now with Django 1.11 each response gets a ETag generated based on response.content. In the case of a x-sendfile response, the response.content is an empty string. So each time the file is accessed, the ETag generated by ConditionalGetMiddleware is the same. Regardless of the changed file/changed mtime.

So now the request has our Last-Modified header AND the Middleware generated ETag.
In get_conditional_response the ETag, which is always the same hash of empty string, is checked first and returns a 304. BUT the Last-Modification has changed and is ignored.

This looks like two bugs for me. First the ETag of the empty content string from x-sendfile respose. Second returning a 304 if ETag is the same but Last-Modified has changed.

[Tim Graham]

If there are two bugs, there should be two tickets. Will you offer some fixes?

[Windson yang]

I can try to fix it. But it may take one week for me.

[Flavio Curella]

I've created a ticket for the 304 issue: https://code.djangoproject.com/ticket/30812#ticket

[Claude Paroz]

Now that #30812 is fixed, I think this should be closed, as the behavior of returning a 304 if ETag is the same but Last-Modified has changed is conforming to the specs.
See ​https://tools.ietf.org/html/rfc7232#section-6, entity tags are presumed to be more accurate than date validators.

[Mariusz Felisiak]

Agreed, current behavior is RFC7232 compliant.