The WSGI specification provides the wsgi.file_wrapper extension for 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
