My django site is served up with the following in Apache's config:
WSGIScriptAlias /studio /django/studio/bin/django.wsgi
My urls.py looks like:
urlpatterns += patterns(
'django.contrib',
(r'^admin/', include(admin.site.urls)),
(r'^accounts/login/$', 'auth.views.login'),
(r'^accounts/logout/$', 'auth.views.logout'),
)
...and yet:
[<a href="{% url admin:index %}">admin</a>]
...generates a link to /admin rather than /studio/admin.
Bizarrely, the urls within the admin interface itself are fine.
I'm using:
Python 2.5.2-3
Django 1.1.1
mod_wsgi 2.5-1~lenny1
apache2 2.2.9-10+lenny6
Can anyone tell me what I'm doing wrong?
cheers,
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
Seems to me you are missing namespace definitions in your URL for that to work.
http://docs.djangoproject.com/en/dev/topics/http/urls/#defining-url-namespaces
Hi All,
My django site is served up with the following in Apache's config:
WSGIScriptAlias /studio /django/studio/bin/django.wsgi
My urls.py looks like:
urlpatterns += patterns(
'django.contrib',
(r'^admin/', include(admin.site.urls)),
(r'^accounts/login/$', 'auth.views.login'),
(r'^accounts/logout/$', 'auth.views.logout'),
)
...and yet:
[<a href="{% url admin:index %}">admin</a>]
...generates a link to /admin rather than /studio/admin.
Bizarrely, the urls within the admin interface itself are fine.
I'm using:
Python 2.5.2-3
Django 1.1.1
mod_wsgi 2.5-1~lenny1
apache2 2.2.9-10+lenny6
Can anyone tell me what I'm doing wrong?
Short of firing up a blank VM, I'm not sure how much more bare bones I
can get :-S
Not sure if it helps but:
- 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
- A workaround which solves the problem for me is to precede the
WSGIScriptAlias in the apache config with:
RewriteRule ^/studio$ /studio/ [R]
cheers,
Chris
PS: I never got my original message mailed back to me from the list, was
I stuck in the google groups moderation queue?
On Dec 26, 7:28 pm, Chris Withers <ch...@simplistix.co.uk> wrote:
> Karen Tracey wrote:
> > Can anyone tell me what I'm doing wrong?
>
> > No idea. I can't recreate by copy & pasting you urlpatterns. Tried on
> > Django 1.1.1 and current trunk. I've got mod_wsgi 2.3 instead of 2.5
> > but I doubt that makes a difference for this -- everything else the same
> > level as yours. Can you recreate with a bare-bones setup?
>
> Short of firing up a blank VM, I'm not sure how much more bare bones I
> can get :-S
As I told you when you tried to use private email to get me to help on
this, try using a simple test program when validating things and not
use a high level framework. See:
http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Displaying_Request_Environment
for a simple test program that echos back WSGI request environment.
The key thing you want to be looking at is the value of SCRIPT_NAME as
is passed in the WSGI environment. If it is /studio then mod_wsgi is
doing exactly what it is meant to and Django or your configuration of
Django is causing a problem.
> - 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()
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.
> - A workaround which solves the problem for me is to precede the
> WSGIScriptAlias in the apache config with:
>
> RewriteRule ^/studio$ /studio/ [R]
Which definitely shouldn't be required unless the WSGI script file is
screwing things up, or you perhaps some other rewrite rule, or
conflicting configuration in Apache configuration and this rule is
short circuiting things so the other rule/configuration directives
don't get a chance to affect things.
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.
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.
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.
Graham
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
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
If anyone can tell me how to do "httpd -X" on a debian or ubuntu host
I'd be very grateful...
If anyone can tell me how to do "httpd -X" on a debian or ubuntu host
I'd be very grateful...
In case anyone else needs it:
apache2ctl -X
*sigh* -> why must the debian guys bugger up everything in their distros?!
For me that gave:
# /usr/sbin/apache2 -X
apache2: bad user name ${APACHE_RUN_USER}
However, as I said in my other thread, what did work for me was:
apache2ctl -X
cheers,
I believe it's a bug in Django:
http://code.djangoproject.com/browser/django/tags/releases/1.1.1/django/core/handlers/base.py#L204
Sadly, still there on the branch and trunk:
http://code.djangoproject.com/browser/django/branches/releases/1.1.X/django/core/handlers/base.py#L215
http://code.djangoproject.com/browser/django/trunk/django/core/handlers/base.py#L215
The problem is when PATH_INFO is empty, as it is in the top case. Python
has no notion of positive or negative zero (;-)) so we end up returning
script_url[:0]...
Now, I'm really curious that Karen says this works for her. Karen, can
you have a look at what's different about your apache setup, as I can't
see how this would ever correctly work for the "root url without the
slash" case.
I have to admit, I can't see why the script name would ever need to be
trimmed like that. Graham, perhaps you might be able to shed some light
with your greater wsgi experience?
> <mailto:ch...@simplistix.co.uk>> wrote:For me that gave:
>
>
> If anyone can tell me how to do "httpd -X" on a debian or ubuntu host
> I'd be very grateful...
>
>
> /usr/sbin/apache2 -X
# /usr/sbin/apache2 -X
apache2: bad user name ${APACHE_RUN_USER}
However, as I said in my other thread, what did work for me was:
apache2ctl -X
Graham Dumpleton wrote:I believe it's a bug in Django:
>
>> 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.
http://code.djangoproject.com/browser/django/tags/releases/1.1.1/django/core/handlers/base.py#L204
The problem is when PATH_INFO is empty, as it is in the top case. Python
has no notion of positive or negative zero (;-)) so we end up returning
script_url[:0]...
Now, I'm really curious that Karen says this works for her. Karen, can
you have a look at what's different about your apache setup, as I can't
see how this would ever correctly work for the "root url without the
slash" case.
I wonder what SCRIPT_URL is and why it's empty for you but not for me?
I wonder if SCRIPT_URL having a value is something that came along with
a later version of mod_wsgi? Could you trying using the debian-packaged
mod_wsgi (whih is version 2.5.x) and see if that changes the behaviour
you observe?
> Since rewrites were mentioned earlier perhaps it's significant that this
> Apache setup doesn't have mod_rewrite enabled.
I don't think so, I've checked with the rewrite engine's logging and all
the urls in question are being passed straight through.
Karen Tracey wrote:I wonder what SCRIPT_URL is and why it's empty for you but not for me?
> In my case, environ.get('SCRIPT_URL', u'') and
> environ.get('REDIRECT_URL', u'') both return empty.
No, I had as thorough a look as I could and could find no issue which
directly covered this issue so submitted a new one:
http://code.djangoproject.com/ticket/12464
Sadly, Trac ate the indentation :-(
cheers,
return HttpResponseRedirect(reverse('admin_url'))
Instead of redirecting to /studio/admin/ it redirects to /admin/
So, while /studio/admin/ resolves well, reversing the path doesn't
yield the reverse.
I'm using Django 1.1.1 and mod_wsgi 2.5
Unfortunately adding the rewrite rule mentioned as a work around
hasn't worked for me.
-Shane
Please post the relevant section of your Apache config (including your
wsgi *and* rewrite lines), there's no reason the rewrite rule workaround
shouldn't work for you...