You would have to handle range headers yourself in application that is
just how WSGI is. That is, WSGI expects everything to be done in
For it to work, just open file in 'rb' mode, seek to appropriate
position in file, set Content-Length for how much you want sent and
then wrap it in wsgi.file_wrapper and return it.
Note that mod_wsgi is however probably the only WSGI hosting mechanism
available which will actually look at the Content-Length returned for
wsgi.file_wrapper and only send that much of the file from the current
seek position. All other WSGI hosting adapters I have seen will just
return from current seek position to end of file. Thus the others
could return much more data than necessary and it would be up to
client to ignore what was returned in excess of the content length.
Even the FileWrapper example in WSGI PEP explaining what to use when
wsgi.file_wrapper isn't supported by WSGI adapter doesn't look at
Content-Length. Thus, if using FileWrapper to support other WSGI
adapters without wsgi.file_wrapper extension, you may want to modify
the FileWrapper example from WSGI PEP to honour Content-Length.
That all said, you may thus have problems adding this support in
Django if mod_wsgi which handles it properly.
May have been a holiday away from home, but was actually doing some
work remotely for my real job a continent away. They even rang me up
so I could sit in on hour long meetings. Charge over 20 hours one
Anyway, my wife says I am addicted to computer/Internet, but finding
time while looking after baby makes it hard these days.
It is probably not that bad when thinking about it as you can just use
a custom FileWrapper for WSGI for everything, and if didn't mind
mod_wsgi specific check, use wsgi.file_wrapper when it exists and WGSI
environ contains 'mod_wsgi.version'.
> Maybe WSGI 1.1 could clarify this?
Yeah right. Am not overly optimistic that there will ever be revisions
of WSGI specification these days.
Hmmm, you are right, I am not providing mod_wsgi.version. Wander why
I'm not doing that.