Hi Graham, On Fri, 2009-03-06 at 21:50 -0800, Graham Dumpleton wrote: [...] > I am still toying with whether I add a few things or not. The first of > these is optionally enabled support in daemon mode for X-Sendfile > header where sending of file is actually performed back in main Apache > worker process. Not sure though whether I want to do this or not as it > raises various permissions issues as reading/sending of file not done > as same user as daemon but Apache user. Also, have already added > support to daemon mode for CGI style Location header redirect when > status is 200. This is like X-Accel-Redirect in nginx in that the URL > goes back through Apache request matching and so governed by Apache > permissions module and target of internal redirect can be dynamic > application as well as static. As such, have preference for just that > at the moment, but might be convinced otherwise. This all may be > relevant as I noted some discussion on a Django ticket in relation to > wsgi.file_wrapper about having X-Sendfile support as well or instead > of it.
I'll bump up the priority of getting that ticket resolved (probably Monday), then. I'd sort of been thinking it was all just settled, but if there's still some decision to be made, best make it soon. Thanks for the heads up. > > The second thing am thinking about is some sort of automatic support > for fixing up WSGI request environment when Apache/mod_wsgi put behind > a proxy and so need to deal with X-Forwarded-Host, X-Forwarded-For and > X-Forwarded-Proto. I know some frameworks have some support for this, > but not sure if Django does. What one normally has to do with WSGI is > add a top level middleware which does the fixup, but thinking ahead > for commodity hosting mechanism interested in way that hoster could > automatically set it up and user not have to worry about it. Feedback > on whether Django does anything with these headers would be helpful. Django uses X-Forwarded-Host for host detection in the HttpResponse object. The X-Forwarded-For header is also used in some (highly optional) middleware to set the remote address. We don't read X-Forwarded-Proto at all, which is probably a bit inconsistent. Documentation at http://docs.djangoproject.com/en/dev/ref/middleware/#reverse-proxy-middleware for the only X-Forwarded-For usage and http://docs.djangoproject.com/en/dev/ref/request-response/#django.http.HttpRequest.get_host for X-Forwarded-Host. I've kind of been advocating (although not very strongly) that we ditch support for that range of X-* headers, though, since they tend to be a bit inconsistently implemented and I really believe that if some web server is going to change those values, they're also responsible for setting them back. Regards Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
