On Dec 26, 11:18 pm, Chris Withers <ch...@simplistix.co.uk> wrote:
> Graham Dumpleton wrote:
>
> > As I told you when you tried to use private email to get me to help on
> > this,
>
> Apologies for that, I was actually trying to use Google's web UI to
> reply to that thread in context. Their UI obvious sucks more than I
> realised as it just sent a private mail to you :-(
>
> >> - I'm running the whole project out of a buildout using djangorecipe
> >> 0.20 (although I did trace through the django.wsgi file and all the work
> >> is still done by django.core.handlers.wsgi.WSGIHandler
>
> > Yes, but what exactly does the WSGI script file contain in regard to
> > the 'application' object. For Django it normally would be:
>
> > import django.core.handlers.wsgi
> > application = django.core.handlers.wsgi.WSGIHandler()
>
> Yup, djangorecipe's script sets application to an instance of
> django.core.handlers.wsgi.WSGIHandler(), not a subclass and with no
> apparent buggering around with the environment.
>
> > If that buildout recipe is doing anything else fancy in it and is
> > modifying the WSGI environment, especially the values of SCRIPT_NAME
> > and PATH_INFO, then it could be stuffing it all up.
>
> Nope, can't see any evidence of this...
>
> > What you should do is disable that rewrite rule and then enable Apache
> > rewrite rule logging to see what other rewrites are occurring in case
> > there is something else which is playing with the URL which shouldn't
> > be.
>
> Once the controversial rewrite rule is disabled and I have rewrite
> logging enabled, I get straight pass through when I visit any of:
>
> /studio
> /studio/
> /studio/subdir
>
> > The best first step though on working this out though is that test
> > program you were pointed to in the documentation. Use it instead of
> > Django and then post examples of the WSGI environment for requests:
>
> > /studio
> > /studio/
> > /studio/subdir
>
> > Ensuring you don't have that rewrite rule in place.
>
> Okay, so I put the debugging app you linked to in test.py and now have:
>
> WSGIScriptAlias /studio /django/studio/bin/django.wsgi
> WSGIScriptAlias /test /django/test.py
>
> I also added a <pre>{{request}}</pre> to the base.html of the django
> app. Here's the output of the request's SCRIPT_NAME for various urls:
>
> /studio - u''
> /studio/ - u'/studio'
> /test - '/test'
> /test/ - '/test/'
Hmmm, that would suggest that it is Django that is changing it for
some reason.
> > Also post all mod_wsgi relevant bits of your Apache configuration so
> > can see what else you have in there. If you had for example other
> > configuration, especially WSGIScriptAliasMatch or ScriptAliasMatch
> > directives that also match, then they could be getting applied and
> > causing issues if the way you used those directives is wrong, as they
> > can have side affects of modifying SCRIPT_NAME and PATH_INFO and the
> > relationships between them.
>
> Other than the above two WSGIScriptAlias directives, there are no
> mod_wsgi directives or ScriptAlias*'s...
>
> How can I step through execution from the django.wsgi file and see where
> I get to? I'm guessing putting an "import pdb; pdb.set_trace()" in the
> django.wsgi file won't do what I want?
Sort of, but you have to run Apache in single process mode. See
further down in same document on debugging.
http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Python_Interactive_Debugger
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-us...@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.
