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/'
> 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?
cheers,
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
--
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.
