Opened 7 years ago
Last modified 5 years ago
#29241 closed Bug
ConditionalGetMiddleware and x-sendfile — at Version 1
| Reported by: | TZanke | Owned by: | nobody |
|---|---|---|---|
| Component: | Core (Cache system) | Version: | 1.11 |
| Severity: | Normal | Keywords: | sendfile |
| Cc: | Triage Stage: | Accepted | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description (last modified by )
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.
If there are two bugs, there should be two tickets. Will you offer some fixes?