Re: Django and Python Warnings
On Sat, Mar 7, 2009 at 12:50 AM, Graham Dumpleton wrote: > 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. For the sites I work on, mod_wsgi is already basically perfect (to the point that I usually don't bother reading the release notes when I upgrade since I've already got everything I need). The only exception would be, yes, X-Sendfile support -- I have a number of apps that need to allow some sort of authenticated file downloads. Over time I've played with mod_xsendfile, lighttpd's mod_secdownload, Perlbal's X-Reproxy-* stuff, and nothing really beats the convenience of X-Sendfile, including mod_python's direct ``req.sendfile`` thing. Yes, the security concerns you mention are a possible concern, especially for folks on shared hosts, and I'd completely understand leaving the feature out because of those concerns -- in my book, security trumps features every day. There's enough other ways of accomplishing the same task that I don't see it as a hugely important feature, but there's no denying that it'd be convenient. Jacob [And thanks for your comments on #2131; I hadn't thought fully through all the different options there, so it's good to have the refresher.] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django and Python Warnings
On Mar 7, 7:29 pm, Malcolm Tredinnick 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 -~--~~~~--~~--~--~---
Re: Django and Python Warnings
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 -~--~~~~--~~--~--~---
Re: Django and Python Warnings
On Mar 7, 12:50 pm, Malcolm Tredinnick 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 > > 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 -~--~~~~--~~--~--~---
Re: Django and Python Warnings
On Fri, 2009-03-06 at 18:12 -0500, Jacob Kaplan-Moss wrote: > On Fri, Mar 6, 2009 at 5:56 PM, Graham Dumpleton > 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. 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.html and http://blog.dscpl.com.au/2009/02/source-code-reloading-with-modwsgi-on.html 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 -~--~~~~--~~--~--~---
Re: Django and Python Warnings
On Fri, Mar 6, 2009 at 5:56 PM, Graham Dumpleton 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. Jacob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django and Python Warnings
On Mar 7, 2:53 am, Jacob Kaplan-Moss wrote: > On Fri, Mar 6, 2009 at 9:46 AM, Brian Neal wrote: > > I updated my working copy of Django after a long period and was > > browsing the source and noticed it was taking advantage of the Python > > warnings module. What is the best way to "see" such warnings when > > doing development? Is it possible to configure Python or the Django > > development server to display such warning messages? > > You want the ``-W`` flag to the python binary; see ``python --help`` > for more. Essentially, you'll do:: > > python -Wall manage.py runserver The issue of warnings came up recently in TG list, as apparent TG2 gets a load form third party packages it uses with newest versions of Python. 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? For Python 2.6 (in mod_wsgi 3.0), it already has a directive to enable Py3K warnings, but not the -W option equivalent. 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 -~--~~~~--~~--~--~---
Re: Django and Python Warnings
On Fri, Mar 6, 2009 at 9:46 AM, Brian Neal wrote: > I updated my working copy of Django after a long period and was > browsing the source and noticed it was taking advantage of the Python > warnings module. What is the best way to "see" such warnings when > doing development? Is it possible to configure Python or the Django > development server to display such warning messages? You want the ``-W`` flag to the python binary; see ``python --help`` for more. Essentially, you'll do:: python -Wall manage.py runserver Jacob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Django and Python Warnings
I updated my working copy of Django after a long period and was browsing the source and noticed it was taking advantage of the Python warnings module. What is the best way to "see" such warnings when doing development? Is it possible to configure Python or the Django development server to display such warning messages? For example, I was still using admin.site.root instead of include (admin.site.urls) in my URLConf. I see the new code now issues a PendingDeprecationWarning for this usage, however I didn't see it in my development server window. I'm guessing I need to turn these on somehow? Thanks. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
