Opened 3 years ago

Last modified 6 weeks ago

#22479 assigned New feature

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

Reported by: Nick Sandford Owned by: Nick Sandford
Component: HTTP handling Version: master
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


Change History (11)

comment:1 Changed 3 years ago by Nick Sandford

Needs documentation: set
Needs tests: set
Triage Stage: UnreviewedAccepted

comment:2 Changed 3 years ago by Nick Sandford

Has patch: set
Owner: changed from nobody to Nick Sandford
Patch needs improvement: set
Status: newassigned

comment:3 Changed 3 years ago by Tim Graham

Did you have any thoughts on adding gunicorn support for runserver (#21978) as a possible way to avoid this?

comment:4 Changed 3 years ago by Nick Sandford

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 Changed 3 years ago by Tim Graham

Cc: Tim Graham 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 Changed 3 years ago by Nick Sandford

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 Changed 3 years ago by Claude Paroz

#23382 was closed as duplicate, and has a different patch proposed:

comment:8 Changed 3 years ago by Alper Cugun

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 Changed 3 years ago by Matt Johnson

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 Changed 2 years ago by Collin Anderson

Cc: cmawebsite@… added

I have some rough, but working code here:

Last edited 16 months ago by Collin Anderson (previous) (diff)

comment:11 Changed 6 weeks ago by

Cc: amlau@… added
Note: See TracTickets for help on using tickets.
Back to Top