On Mar 7, 7:29 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> 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.
I have dumped some relevant information about this on:
http://code.djangoproject.com/ticket/2131#comment:29
This includes highlighting that X-Sendfile isn't the only such header
and some systems also support a URL redirection as mentioned for
nginx. The perbal package also has different headers and supports both
URL redirection and sending of files.
> > 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-mi...
>
> for the only X-Forwarded-For usage and
>
> http://docs.djangoproject.com/en/dev/ref/request-response/#django.htt...
>
> 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.
That it isn't necessarily consistent is what worried me a bit as far
as implementing such a mechanism. :-(
Graham
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
