Opened 11 years ago
Last modified 21 months ago
#22479 new New feature
Support byte range requests in django.views.static.serve
Reported by: | Nick Sandford | Owned by: | |
---|---|---|---|
Component: | HTTP handling | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Tim Graham, cmawebsite@…, amlau@… | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | yes |
Needs tests: | yes | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
As supported by this google groups discussions: https://groups.google.com/d/msg/django-developers/NZ1qTkZ6vok/fhdz7rTtL1EJ
Change History (12)
comment:1 by , 11 years ago
Needs documentation: | set |
---|---|
Needs tests: | set |
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 11 years ago
Has patch: | set |
---|---|
Owner: | changed from | to
Patch needs improvement: | set |
Status: | new → assigned |
comment:3 by , 11 years ago
Did you have any thoughts on adding gunicorn support for runserver (#21978) as a possible way to avoid this?
comment:4 by , 11 years ago
Does gunicorn support it? I'm not sure it does (there are no mentions of "Range" in the source at all), in which case it's not avoidable unless we add support into gunicorn instead?
comment:5 by , 11 years ago
Cc: | added |
---|
I don't know, but if we are adding runserver support for something that's not even supported by what I think is a fairly common web server, that seems like it will only encourage more people to use runserver in production.
I'd echo Russ's sentiments from the django-developers thread: "rather than add a bunch of features to a view in Django and then try to describe when you shouldn't use it, I'd prefer to use that effort to replace the devserver with something equally easy to use, but based off a base that is an actual real live web server. That way, we'd end up with a "devserver", but it would be an actual server, not a hack with a bunch of "please don't actually use this" warnings, we don't end up spending a bunch of time developing a feature that is already implemented better elsewhere, and it would be one step closer to having production mirror development."
Would be great to at least do some investigation to see if this might be feasible even if gunicorn isn't the ultimate answer.
comment:6 by , 11 years ago
Good points, it would be great if we could get closer to dev/prod parity. But sometimes I don't have a need for something rock-solid and production tested, and instead I just want things to "easily" work. I don't think gunicorn or the 'static' python library (used by dj_static) support partial content, and I've only had the need for it to be supported recently due to serving video content on a small internal application. This internal application is still reverse proxied via nginx, and serving content via gunicorn and django.views.static.serve
. Werkzeug does support partial content, but not for multipart/byterange requests (not sure if this is a big deal).
The use-case for supporting it in django.views.static.serve
is that this application of ours runs in a container via docker. Without the support I am faced with two decisions: I could map out the static and media dirs to the host, and share the filesystem from the host to our nginx server and serve it like that, or run an instance of nginx (or another http server) directly within the container. Both of the options are time-consuming, require oodles of extra configuration, and are probably not ideal. We just need something simple that works for serving video content that supports seeking within the video. The application won't be serving millions of requests. If it was, I certainly wouldn't be using this support, I would opt for a different solution. But it doesn't mean we shouldn't support it at all :).
It would be good to move away from the devserver, but also, it would be useful to support partial content in django.views.static.serve
so that things just work in the meantime. Maybe not ideal, but pragmatic?
comment:7 by , 10 years ago
#23382 was closed as duplicate, and has a different patch proposed: https://github.com/satchamo/django/commit/2ce75c5c4bee2a858c0214d136bfcd351fcde11d
comment:8 by , 10 years ago
I would settle for a separate package that does this, but as it stands now for trying things out having to setup nginx on my local machine is a bit too much work.
comment:9 by , 10 years ago
What is the preferred way to implement this feature? I went the simplest route and hacked on just django.views.static.serve
whereas slurms creates a reusable PartialHttpResponse class. My implementation does not support multipart/byteranges requests, but slurms' does. (I don't know of any user-agent that makes those kinds of requests though.)
comment:10 by , 10 years ago
Cc: | added |
---|
I have some rough, but working code here: http://stackoverflow.com/a/35928017/131881
comment:11 by , 8 years ago
Cc: | added |
---|
comment:12 by , 21 months ago
Owner: | removed |
---|---|
Status: | assigned → new |
Pull request here: https://github.com/django/django/pull/2594.