On Monday, March 28, 2011 9:15:45 PM UTC+11, Gustavo Narea wrote: > > On 26/03/11 11:31, Graham Dumpleton wrote: > > > > Yes and no as nginx also has a X-Sendfile module, again possibly > > optional (can't remember). > > I didn't know there was an X-Sendfile module for Nginx -- Search results > for "nginx xsendfile" point me to X-Accel-Redirect >
You could be right and there isn't a X-Sendfile for module for nginx. As I said I couldn't remember. :-) > > > > Add to this wsgi.file_wrapper and you have three different schemes one > > can use. For the case of URL mechanism, there also various headers and > > consumers of the headers. > > I think wsgi.file_wrapper is a different beast. I would not try to > support it along with X-Sendfile/X-Accel-Redirect/Location. > But wsgi.file_wrapper, and its graceful fallback as documented in WSGI PEP, is the only one actually guaranteed to work without a silent failure. Ie., you are always guaranteed to get a response still where as with the others, if no front end web server actually supports it or is enabled properly, then you just end up with an empty response and the header passed back to the client. Thus it actually potentially makes much more sense to have the default be to take a filesystem path and then use wsgi.file_wrapper to return content. This could then optionally be overridden to use one of the other mechanisms, with a user supplying a mapping function as necessary to translate the file system path into a URL in the case of Location, X-Accel-Redirect or the headers used by the other front end load balancing products. Conceptually, the configuration mechanism could even support the concept of certain file system path prefixes being served up in different ways by different parts of the front end infrastructure. This configuration could be defined as part of the Django settings file for a project. Graham -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.