FWIW, I think the general consensus is that mod_wsgi wins over
modpython these days. I don't speak for core devs, but that's my
thought. Thanks for your work, Graham.
Isn't this basically what wsgi.file_wrapper does? With this patch
HttpResponseSendFile (should probably be HttpResponseFileWrapper) is
used to hand the file off to the wsgi server which takes over and
leaves Django to continue on with other requests.
Justin
Is there a way to abstract this server-specific method of
returning large-but-authenticated files? I have an item on my
plate of things to do that includes returning media (images,
audio, and video) to authenticated users, and I'd like to keep my
code fairly server-agnostic. Solutions were described above for
nginx and wsgi, which mostly leaves mod_python as the remaining
"big" way of serving for which a solution hasn't been listed (if
there is one). For the smaller content, I can just use
authenticated static-media serving. But for the big content, it
could drag a server to its knees pretty quickly with a 500 meg
video file. :)
Yeah, I know the proximity to 1.0 doesn't make this immediately
likely, but maybe post-1.0? It's certainly new stuff, not "get
existing stuff right for 1.0".
-tim
hi,
if that's the case, isn't it possible to end the "processing" path
with a redirect?
i mean, when you finish the "processing", is it really necessary to
serve the file?
couldn't you just send back a http-redirect?
that way even for the first request, you could serve the image
directly by the webserver
gabor
if that's the case, isn't it possible to end the "processing" path with a redirect?
Yes, this is one of the alternatives we're considering. The others are:
1) Just write a separate application outside of Django
2) Hack Django to give access to the underlying mod_wsgi file_wrapper
interface
Yes, this is one of the alternatives we're considering. The others are:
1) Just write a separate application outside of Django
2) Hack Django to give access to the underlying mod_wsgi file_wrapper
interface
Thomas, what server are you using? I believe that lighttpd supports the X-Sendfile header, and Apache does as well if you're running with mod_xsendfile. If you've got such a setup you can serve up the file by doing something like:
Internal redirection to file or URL(s)HTH,
- Big one for us; a backend can instruct Perlbal to fetch the user's data from a completely separate server and port and URL, 100% transparent to the user
- Can actually give Perlbal a list of URLs to try. Perlbal will find one that's alive. Again, the end user sees no redirects happening.
- Can also redirect to a file, which Perlbal will serve non-blocking. See webserver mode above.
yes, i understand. but i assumed based on the original poster's comments
that it's ok, because he said:
>> Subsequent requests can bypass Django and be served directly by the
>> webserver.
> Thomas, what server are you using? I believe that lighttpd supports the
> X-Sendfile header, and Apache does as well if you're running with
> mod_xsendfile.
nginx can do something very similar too:
http://wiki.codemongers.com/NginxXSendfile
gabor
I'm in a similar situation where authorized users can generate a lot
of different reports in PDF format. The files are clearly not static
and while I probably can just save them with random names so random
URI attacks are hard to perform, I would then need to setup a cron job
to remove old files (and an individual could easily DoS the service by
performing a lot of requests until the machine runs out of disk
space).
--
Patryk Zawadzki