wsgi.file_wrapper and range headers

[Graham Carlyle]

Hi

I'm using django with mod_wsgi to dynamically serve some PDFs from a
website. I'm patching django in order to utilise the file_wrapper
speedup...

http://code.djangoproject.com/ticket/7894

So my question is .. how can i support range headers with the
file_wrapper speedup? My tests suggest that the range header is being
ignored with the whole file being returned.

I'm trying to get this to work as it seems the Adobe Acrobat 7.0 PDF
plug-in on Windows causes Firefox to fail downloading the PDF unless
it can retrieve the file using range headers.

I'm guessing that mod_wsgi isn't trying to support the range header
and so I either have to deal with it in my webapp which seems a shame
as apache already has the functionality, or I have to use something
like a caching proxy infront of apache (say squid).

thanks,
Graham

[Graham Dumpleton]

2008/7/23 Graham Carlyle <gra...@grahamcarlyle.com>:

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
application.

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.

Graham

[Graham Carlyle]

On Jul 23, 1:42 pm, "Graham Dumpleton" <graham.dumple...@gmail.com>
wrote:

> 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
> application.
>
> 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.

ok, thanks for the advice

> That all said, you may thus have problems adding this support in
> Django if mod_wsgi which handles it properly.

Yeah I was thinking the django patch would only try to support the
whole file, given the ambiguities over some WSGI adaptors ignoring
content-length. Maybe WSGI 1.1 could clarify this?

Thanks for the comments on the django ticket. I'll try to update the
patch to cover your comments regarding content-length and supporting
mod_python; as I understand it you're suggesting that a file_path be
specified in the interface rather than a file object in order for
other handlers such as mod_python to be supportable.

BTW - you're far too diligent, if I was on holiday I wouldn't be
touching a computer.

cheers,
Graham

[Graham Dumpleton]

> BTW - you're far too diligent, if I was on holiday I wouldn't be touching a computer.

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
week. :-)

Anyway, my wife says I am addicted to computer/Internet, but finding
time while looking after baby makes it hard these days.

Graham

[Graham Dumpleton]

2008/7/23 Graham Carlyle <gra...@grahamcarlyle.com>:

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.

Graham

[Graham Carlyle]

On Jul 24, 3:06 am, "Graham Dumpleton" <graham.dumple...@gmail.com>
wrote:

> 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'.

I think I've updated the patch on the django ticket in-line with what
you said but I found that mod_wsgi.version wasn't being set in the
environment so I switched on mod_wsgi.callable_object being present
instead.

cheers,
Graham

[Graham Dumpleton]

2008/7/29 Graham Carlyle <gra...@grahamcarlyle.com>:

Hmmm, you are right, I am not providing mod_wsgi.version. Wander why
I'm not doing that.

Graham

> cheers,
> Graham
> >
>