On Mar 7, 12:50 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> On Fri, 2009-03-06 at 18:12 -0500, Jacob Kaplan-Moss wrote:
> > On Fri, Mar 6, 2009 at 5:56 PM, Graham Dumpleton
> > <graham.dumple...@gmail.com> wrote:
> > > Anyway, the issue is that at the moment mod_wsgi doesn't have an
> > > equivalent for the command line -W option. Do people feel it would be
> > > useful to have a directive in mod_wsgi which allows one to control the
> > > warnings mechanism, ie., does the same as -W?
>
> > It's probably useful. Frankly, though, I'm only using mod_wsgi for
> > production, not development, and I'd never let code spewing warnings
> > make its way into production. So doesn't help/hurt me personally, but
> > it's probably useful for less strict development environments.
>
> I think it would be worthwhile if not too painful to add, Graham.
BTW, if there is anything else you would like to see in mod_wsgi, now
is the time to speak up as am close to point where can wrap up work on
mod_wsgi 3.0.
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.
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.
If interested to know what is coming in mod_wsgi 3.0 have a look at:
http://code.google.com/p/modwsgi/wiki/ChangesInVersion0300
I probably should blog about mod_wsgi 3.0 and reference this as a way
of getting feedback. :-)
Graham
> I like the recent post you did on Django development under mod_wsgi and
> want to encourage people to use that more frequently Being able to see
> warnings the framework will raise in development is pretty important
> (otherwise, they'd be errors, not warnings), so that will help there.
>
> By the way, for those not following what Graham's written, (a) shame on
> you! and (b) see
>
> http://blog.dscpl.com.au/2008/12/using-modwsgi-when-developing-django...
>
> and
>
> http://blog.dscpl.com.au/2009/02/source-code-reloading-with-modwsgi-o...
>
> 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
-~----------~----~----~----~------~----~------~--~---
