[Django] #24158: Static serve failure since 1.4.18
Django
-------------------------------+-------------------------
Reporter: TheRealEckat | Owner: nobody
Type: Uncategorized | Status: new
Component: Generic views | Version: 1.4
Severity: Normal | Keywords: development
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+-------------------------
With version 1.4.18 a change modified django.views.static.serve at line 65
for reading the file.
HttpResponse is called with the iter object, but this can't do anything
with that.
From Django 1.5 the CompatibleStreamingHttpResponse is used at this point.
Reproducible by adding
{{{
if settings.DEBUG:
urlpatterns += patterns('',
url(r'^media/(?P<path>.*)$', 'django.views.static.serve', {
'document_root': settings.MEDIA_ROOT,
}),
)
}}}
to the urls.py an call a file in that path.
The Response status is 200 and the content lenght is transmitted
correctly.
In fact, only 0 bytes transferred.
A possible fix is, to change the line to
{{{
response = HttpResponse(''.join(iter(lambda:
f.read(STREAM_CHUNK_SIZE), '')), mimetype=mimetype)
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/24158>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: TheRealEckat | Owner: nobody
Type: Bug | Status: new
Component: Generic views | Version: 1.4
Keywords: development | Triage Stage: Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by TheRealEckat):
* needs_better_patch: => 0
* type: Uncategorized => Bug
* needs_tests: => 0
* needs_docs: => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/24158#comment:1>
Django
Reporter: TheRealEckat | Owner: nobody
Type: Bug | Status: new
Component: Core (Other) | Version: 1.4
Severity: Normal | Resolution:
Keywords: development | Triage Stage: Unreviewed
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* component: Generic views => Core (Other)
Comment:
I can't reproduce this problem on Python 2.7; serving files seems to work
just fine. What version of Python are you using? Are you using a browser
to request the files or something else?
--
Ticket URL: <https://code.djangoproject.com/ticket/24158#comment:2>
Django
Reporter: TheRealEckat | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 1.4
Severity: Normal | Resolution:
Keywords: development | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* type: Bug => Cleanup/optimization
* component: Core (Other) => Documentation
* stage: Unreviewed => Accepted
Comment:
Actually, it seems likely that this is caused by one of your middlewares
consuming the iterator prematurely, see the
[https://docs.djangoproject.com/en/dev/releases/1.5/#explicit-support-for-
streaming-responses 1.5 release notes]. We could document this caveat in
the 1.4.18 release notes if it seems appropriate. Your proposed change
would negate the benefit of the security fix.
--
Ticket URL: <https://code.djangoproject.com/ticket/24158#comment:3>
Django
Reporter: TheRealEckat | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 1.4
Severity: Normal | Resolution:
Keywords: development | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by TheRealEckat):
Replying to [comment:2 timgraham]:
> I can't reproduce this problem on Python 2.7; serving files seems to
work just fine. What version of Python are you using? Are you using a
browser to request the files or something else?
I use python 2.7.
A colleague can reproduce this problem.
I located a potential problem with the middlewares, but I commented them
one by one out.
After first middleware, the length od the response is always zero.
The first two one in my settings are custom middlewares, but the third is
the django CsrfViewMiddleware. This middleware does the same, the response
length is then zero.
Thanks for the hint with the documentation of django 1.5, I'll check it on
monday.
--
Ticket URL: <https://code.djangoproject.com/ticket/24158#comment:4>
Django
Reporter: TheRealEckat | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 1.4
Severity: Normal | Resolution:
Keywords: development | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by TheRealEckat):
UPDATE:
The problem is located in django.middleware.gzip.GZipMiddleware.
If I comment out the gzip middleware, the output is looking good.
--
Ticket URL: <https://code.djangoproject.com/ticket/24158#comment:5>
Django
Reporter: TheRealEckat | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 1.4
Severity: Normal | Resolution:
Keywords: development | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by kilrogg):
I can reproduce this.
Using the GZipMiddleware on 1.4.18 and the static.serve view results in
all served files having empty content.
Curiously it works for serving static files via static files contrib app
which uses said view as well.
In 1.5 GZipMiddleware was changed to check for Streaming response, same
could be backported to 1.4 checking response content for GeneratorType.
--
Ticket URL: <https://code.djangoproject.com/ticket/24158#comment:6>
Django
Reporter: TheRealEckat | Owner: nobody
Type: Bug | Status: new
Component: HTTP handling | Version: 1.4
Severity: Normal | Resolution:
Keywords: development | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by kilrogg):
* type: Cleanup/optimization => Bug
* component: Documentation => HTTP handling
Comment:
I opened Pull request #3987 with a fix for GZipMiddleware:
https://github.com/django/django/pull/3987
I backported django.utils.text.compress_sequence and some of the newer
GZipMiddleware code to 1.4 to check for response._base_content_is_iter
before consuming response.content and added handling of iterables in
responses.
This bug also happens when returning HTTPResponse(iter(...)) in any view.
Is this a feasible solution? Was it okay to recategorize this ticket?
This is my first django ticket I'm working on, so any feedback is very
welcome.
--
Ticket URL: <https://code.djangoproject.com/ticket/24158#comment:7>
Django
Reporter: TheRealEckat | Owner: timgraham
Type: Bug | Status: assigned
Component: HTTP handling | Version: 1.4
Severity: Normal | Resolution:
| checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* owner: nobody => timgraham
* status: new => assigned
* has_patch: 0 => 1
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/24158#comment:8>
Django
Reporter: TheRealEckat | Owner: timgraham
Component: HTTP handling | Version: 1.4
Keywords: development | Triage Stage: Ready for
| checkin
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham <timograham@…>):
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"1e39d0f6280abf34c7719db5e7ed1c333f5e5919"]:
{{{
#!CommitTicketReference repository=""
revision="1e39d0f6280abf34c7719db5e7ed1c333f5e5919"
[1.4.x] Fixed #24158 -- Allowed GZipMiddleware to work with streaming
responses
Backport of django.utils.text.compress_sequence and fix for
django.middleware.gzip.GZipMiddleware when using iterators as
response.content.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/24158#comment:9>