Support byte range requests in django.views.static.serve

[md...@pdx.edu]

Is the Django community interested in supporting HTTP range requests in django.views.static.serve?

The primary benefit I see is that it makes files served up for <video> and <audio> "seek-able" with the django server. This generally isn't a problem for small files (except in Chrome), but becomes an issue for larger ones.

Werkzeug has a function that parses the range header, which I used to support range requests in a Django application. I estimate that robust support for HTTP range requests would cost <300 lines of code, plus tests.

[Russell Keith-Magee]

On Mon, Apr 14, 2014 at 11:30 AM, <md...@pdx.edu> wrote:
> Is the Django community interested in supporting HTTP range requests in
> django.views.static.serve?
>
> The primary benefit I see is that it makes files served up for <video> and
> <audio> "seek-able" with the django server. This generally isn't a problem
> for small files (except in Chrome), but becomes an issue for larger ones.

My immediate inclination is to say No - for the reason that is listed
at the very top of the source file in question:

https://github.com/django/django/blob/master/django/views/static.py

"""
These are only to be used
during development, and SHOULD NOT be used in a production setting.
"""

One of the easiest ways to make sure that a feature isn't used in
production is to ensure that it doesn't have features that would be
useful in production. Supporting ranged downloads for static files
strikes me as exactly that sort of feature.

My opinion - If you need to test ranged downloads of static files,
then fire up a real web server - like gunicorn - in your development
environment. This isn't something that should be added to Django.

Yours,
Russ Magee %-)

[Alex Gaynor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I'd be +1 on doing this -- I know we've always said that Django's static serve isn't for production use, but as video and audio are increasingly common on the web, Django should support them seemlessly.

Alex

PS: I'm of course open to other ways of supporting these, such as using Twisted for static file serving. (0.5 wink ;-)

-----BEGIN PGP SIGNATURE-----
Version: Mailvelope v0.8.0
Comment: Email security by Mailvelope - http://www.mailvelope.com

wsFcBAEBCAAQBQJTS1l0CRASX1xn3+lAhAAAzhAP/RJ5RA4zXF8/sog+snpf
ZhxObrYh04irkjQDcV7Jzs80tsgTWuhZBQgrlPR9ESfsOcIDSTStGGZsDFyR
y7VnFCa0RFsE/jXi3tkig2VFiK9cNIYbRNyzwETiOVBoiUeP52nq/TUVkAOD
UUmLbV9wdEXFAc/i/dkgJk4HxIYjzqURMFJ5S+XPi/6jwEF9Ds16ORONPY9o
nTC9c1auzra91HqxDs/n5OTg8L9p80y3QRrsHx2vrCP7R1yPyteuqeWVd1Lk
zqvj5/bwHRcMR0Q/oXnjvG3UJuOf+nx3s2o6hFoAHiVfXsrIMOUv/PTnr+Ck
ayj7+lrRr+wpOr0rfgARFpLv1GggNaug2ZnFfLVGJZ+VGBJ1nWmDq+j8bMEI
zUEPBUw+BxDWoQXdNUacl9J16YerUw5aaTEzTppwNg65UU6YobvaToSe5Dqe
nto/8dW/JBXC7YeRCXSxaOoJnX6A7rnI7Typr2pB6PcWPjevSZYxrXuf1Cf3
YG/5fQ6FRbuh2SevQGO634RiEkr/Z6DbDlEINCBvLPx692aJ31IFOmJSF+ds
AtDYeJjzDf6oKVdqlMJ0mAft1BIjUzpOGvgMjhQpss4cZBDWHID1T5ZUHdVL
H7Q+0JAskdC8Oa6BrveGydZZfcQpYyy1sghxwxaXqwKguc8gTwcw2Wsx59un
waxF
=Ofgw
-----END PGP SIGNATURE-----

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/37cdec22-e19d-4843-a3e4-a6b1e1bfa86e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

GPG Key fingerprint: 125F 5C67 DFE9 4084

[md...@pdx.edu]

Apparently, I don't know how to use Google groups. I think I sent something directly to Russell, and it wasn't posted here. Oops. Here it is again (from memory):

It takes more than just running gunicorn. You'd have to setup Apache or Nginx in front. And if Django needs to handle the request first (for authentication purposes), then you would have to configure something like xsendfile as well.

The Django server was included "so you can develop things rapidly, without having to deal with configuring a production server". If you happen to be developing with HTML 5 video and audio, the Django server doesn't live up to its stated goal.

[Adrian Holovaty]

On Sun, Apr 13, 2014 at 11:30 PM, <md...@pdx.edu> wrote:

Is the Django community interested in supporting HTTP range requests in django.views.static.serve?

I definitely support this.

I've gotten bitten several times by the development server not supporting Range headers, and it's the kind of a problem that is quite hard to debug. I recall it took me about an hour to determine why audio wasn't seeking properly when it was being served by the development server.

To Russ' point about not using the server in production: we can support Range without sacrificing our "don't use this in production" goal. Let's treat our users like consenting adults. We should definitely discourage people from using the development server in production, but not to the point where we're neutering the server, making development more difficult.

Long story short: go ahead and implement that robust support, with tests, and I can take the lead on reviewing the patch. Email me offlist when it's ready, if you could, so I don't lose track of it. Thanks for bringing this up!

Adrian

[Russell Keith-Magee]

On Tue, Apr 15, 2014 at 1:42 AM, Adrian Holovaty <adr...@holovaty.com> wrote:
> On Sun, Apr 13, 2014 at 11:30 PM, <md...@pdx.edu> wrote:
>>
>> Is the Django community interested in supporting HTTP range requests in
>> django.views.static.serve?
>
>
> I definitely support this.
>
> I've gotten bitten several times by the development server not supporting
> Range headers, and it's the kind of a problem that is quite hard to debug. I
> recall it took me about an hour to determine why audio wasn't seeking
> properly when it was being served by the development server.
>
> To Russ' point about not using the server in production: we can support
> Range without sacrificing our "don't use this in production" goal. Let's
> treat our users like consenting adults. We should definitely discourage
> people from using the development server in production, but not to the point
> where we're neutering the server, making development more difficult.

I accept the use case, but I'm still not wild about the solution. I
can certainly accept that making it easier to develop media-rich apps
would be a good thing. However, 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.

This is a lot more plausible now that we have good packaging tools.
There have also been a bunch of vague discussions over the last couple
of years on this topic.

That said, I'm also not especially motivated to work on this
personally - I'm just expressing my architectural concerns. Count me
as a -0, not a -1.

Yours,
Russ Magee %-)

[prathamesh juvatkar]

I am building a music player application with Django + nginx for which I need a backend which supports byte range requests.

Django is authenticating the media file correctly but django dev server does not support range requests (206 partial response). Nginx directly serves byte range requests after using this configuration, I verified that the response header has content range. However I am unable to forward the request from django to nginx, to serve the content.

I tried using X-Accel-Redirect in a django view but still the response header doesn't have content range the way it would have been if the file had been directly served by nginx.

• Django dev server - Authentication done but no byte range support (response 200)
• Nginx - No authentication, byte range request support (response 206)
• Django view + X-Accel-Redirect + nginx - Authentication done but no byte range support (response 200)

So I am trying to find a way to authenticate using Django and provide support for byte range requests with nginx or another static file server.

[phpdude]

can you show the code example for your way #3?

looks like you done this wrong.

i build in past same thing with php (for nginx is not difference in backend when it return only header).

-- 
phpdude

--

You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/dc0e3e53-b065-4201-841d-59ce28255c72%40googlegroups.com.

[ma...@satchamo.com]

Here is the commit for adding HTTP range support. I tested it in late versions of Chrome, Firefox, Opera and IE.

https://github.com/satchamo/django/commit/2ce75c5c4bee2a858c0214d136bfcd351fcde11d

The RangedFileReader class may be superfluous but I'm not aware of anything in Django or the Python standard library that does something like that.

Feedback appreciated.

[Josh Smeaton]

I'm actually +1 on the idea (I haven't looked at the patch). I use django-downloadview for streaming files which has support for the built in django server in development but testing that skipping/range works is impossible without deploying to a real web server.

[md...@pdx.edu]

I made a ticket in the hopes of drawing more attention to the patch:

https://code.djangoproject.com/ticket/23382

On Sunday, April 13, 2014 8:30:37 PM UTC-7, md...@pdx.edu wrote: