Should mod_wsgi support X-Sendfile itself for WSGI applications?
Graham Dumpleton
optimised returning of static files and this extension is supported by
mod_wsgi with Apache/mod_wsgi on UNIX using sendfile() or mmap()
functions where it can.
Another way of responding with static files supported by some systems
is the X-Sendfile response header. For Apache this is supported if
third party mod_xsendfile is loaded into Apache. There is similarly a
mod_xsendfile module for nginx and lighttpd has builtin support for
it. These latter two would obviously only come into play if nginx or
lighttpd were being used as separate static media server and proxy
through to Apache/mod_wsgi running WSGI application.
The question is, should mod_wsgi itself provide support for X-Sendfile
response header for just WSGI applications to make it easier if you
want to use this feature?
My feeling is that it shouldn't, but there has been a little bit of
interest in it doing so since it would avoid the need for separate
Apache mod_xsendfile. So, want to see if anyone has any comments
before I say conclusively that will not be done.
First reason why I don't want to support is that it would only be
trivial to implement for mod_wsgi daemon mode.
Second is that it side steps the Apache security model whereby Apache
configuration can control from where files are served up. Yes when
using wsgi.file_wrapper you are also side stepping Apache security,
but the difference there is that since this would only work for daemon
mode anyway, that code is at least running as the same user as the
WSGI application. For X-Sendfile it would be handled back in the
Apache server child process and run as Apache user. Thus it has
different access rights than the WSGI application. This could result
in failure to be able to access a file, or ability to access files
that the WSGI application didn't have access to.
Third reason is that mod_wsgi 3.0 already supports for mod_wsgi daemon
mode the CGI Location header for internal server URL redirect.
http://code.google.com/p/modwsgi/issues/detail?id=14
This feature is similar to X-Accel-Redirect in nginx and X-Reproxy-URL
(??) in perbal. What it does is issue an internal server redirect
where the input is a URL rather than a file. Thus the request goes
back through all the URL matching rules in Apache and so again
controlled through the Apache security model.
The only thing with Apache at least is that the URL namespace is also
public to external clients for a host. Thus to ensure that a URL is
only accessible to a internal redirect using this feature, you would
need to use mod_rewrite to add conditions that ensure access to
certain URLs is a sub request. In the case of nginx it has a special
configuration keyword to mark such URLs as private and so only
accessible to the internal redirect. Not sure what perlbal does.
Anyway, although Location is not the same in that it is URL
redirection, I feel it actually provides better functionality anyway.
It can still be used for return static files in a special area, you
just need to properly protect that part of the URL namespace so that
they are only accessible to internal sub requests from Apache.
I think that is probably enough rambling. So, does anyone who knows
about X-Sendfile and use it got any comments about all this?
Thanks.
Graham
Nimrod A. Abing
<graham.d...@gmail.com> wrote:
> The question is, should mod_wsgi itself provide support for X-Sendfile
> response header for just WSGI applications to make it easier if you
> want to use this feature?
>
> My feeling is that it shouldn't, but there has been a little bit of
> interest in it doing so since it would avoid the need for separate
> Apache mod_xsendfile. So, want to see if anyone has any comments
> before I say conclusively that will not be done.
If it's already being done by another Apache module then IMHO there is
no compelling reason to implement it in mod_wsgi. True that having
X-Sendfile support should make it more convenient in that you don't
need mod_xsendfile installed. But you already gave 3 reasons why *not*
to implement it. It's a 3-to-1 consensus :) So unless mod_xsendfile
somehow conflicts with mod_wsgi I don't see why one would not just use
an existing solution. If you do decide to implement this in mod_wsgi,
how about making it a compile-time option which is turned off by
default? I believe this should be the default for all "extras" that
are not part of the WSGI spec.
My 2 cents...
--
Best Regards,
Nimrod A. Abing
W http://arsenic.ph/
W http://preownedcar.com/
W http://preownedbike.com/
W http://abing.gotdns.com/
Graham Dumpleton
>
> On Tue, Mar 10, 2009 at 12:35 PM, Graham Dumpleton
> <graham.d...@gmail.com> wrote:
>> The question is, should mod_wsgi itself provide support for X-Sendfile
>> response header for just WSGI applications to make it easier if you
>> want to use this feature?
>>
>> My feeling is that it shouldn't, but there has been a little bit of
>> interest in it doing so since it would avoid the need for separate
>> Apache mod_xsendfile. So, want to see if anyone has any comments
>> before I say conclusively that will not be done.
>
> If it's already being done by another Apache module then IMHO there is
> no compelling reason to implement it in mod_wsgi. True that having
> X-Sendfile support should make it more convenient in that you don't
> need mod_xsendfile installed. But you already gave 3 reasons why *not*
> to implement it. It's a 3-to-1 consensus :) So unless mod_xsendfile
> somehow conflicts with mod_wsgi I don't see why one would not just use
> an existing solution. If you do decide to implement this in mod_wsgi,
> how about making it a compile-time option which is turned off by
> default? I believe this should be the default for all "extras" that
> are not part of the WSGI spec.
It would have been off by default by way of directive. But pretty well
decided that don't want to go down that path. :-)
Thanks for the confirmation/feedback.
Graham