Opened 11 months ago

Last modified 12 days ago

#22479 assigned New feature

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

Reported by: slurms Owned by: slurms
Component: HTTP handling Version: master
Severity: Normal Keywords:
Cc: timo, cmawebsite@… Triage Stage: Accepted
Has patch: yes Needs documentation: yes
Needs tests: yes Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

Change History (10)

comment:1 Changed 11 months ago by slurms

  • Needs documentation set
  • Needs tests set
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

comment:2 Changed 11 months ago by slurms

  • Has patch set
  • Owner changed from nobody to slurms
  • Patch needs improvement set
  • Status changed from new to assigned

comment:3 Changed 11 months ago by timo

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

comment:4 Changed 11 months ago by slurms

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 11 months ago by timo

  • Cc timo 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 11 months ago by slurms

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 7 months ago by claudep

#23382 was closed as duplicate, and has a different patch proposed: https://github.com/satchamo/django/commit/2ce75c5c4bee2a858c0214d136bfcd351fcde11d

comment:8 Changed 6 months ago by alper

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 6 months ago by mdj2

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 12 days ago by collinanderson

  • Cc cmawebsite@… added

I also have some rough, but working code here: https://github.com/collinanderson/djfiles/blob/master/djfiles.py

Note: See TracTickets for help on using tickets.
Back to Top