URL lookup fails in apache/wsgi unless mapped to server root.

[Spaceman Paul]

My application works fine in runserver and in apache/wsgi mapped to root, but when I map wsgi to a directory, url lookups fail.

E.g.

Request URL: http://server/awma/times
...
^times$ [name='times']
...
The current URL, times, didn't match any of these.

Every single URL in the (full) list fails (including "^$", but weirdly enough /admin works fine).

Again, I stress that this all works fine in runserver, and if WSGIScriptAlias is mapped to the server root.

I cannot make sense of this as the URL getting passed to the URL resolver is correct and should match.

Any suggestions?

Python 2.7. 
Django 1.6.5, but I see the same behaviour with Django 1.4.13.

P.

[Kelvin Wong]

Maybe

WSGIScriptAlias /awma /var/www/djangoapp/djangoapp/wsgi.py

K

[Spaceman Paul]

No that's what I've got.

P.

[Kelvin Wong]

Maybe post your apache.conf or/and your wsgi file. Maybe check your Apache logs.

K

[Spaceman Paul]

Nothing in wsgi.conf.

Relevant bits of apache conf:

<VirtualHost *:80>
....
WSGIScriptAlias /awma /home/paul/src/awma-apache/internationalguidelines/wsgi.py
....
</VirtualHost>

Nothing in /var/log/apache2/error.log

Access.log just says:

152.91.9.9 - - [23/May/2014:08:27:17 +1000] "GET /awma/ HTTP/1.1" 404 1476 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0"
152.91.9.9 - - [23/May/2014:08:27:22 +1000] "GET /awma/times HTTP/1.1" 404 1483 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0"

404 debug pages like:

Using the URLconf defined in internationalguidelines.urls, Django tried these URL patterns, in this order:

  1.  ^$ [name='index']
  2.  ^times$ [name='times']
  3.  ^admin/

The current URL, times, didn't match any of these.

AND: The current URL, , didn't match any of these

Although weirdly, admin works:

152.91.9.9 - - [23/May/2014:08:28:19 +1000] "GET /awma/admin/ HTTP/1.1" 200 1450 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0"

But when I change the WSGIScriptAlias to:

 WSGIScriptAlias / /home/paul/src/awma-apache/internationalguidelines/wsgi.py

Everything works fine:

152.91.9.9 - - [23/May/2014:08:37:22 +1000] "GET / HTTP/1.1" 200 1156 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0"
152.91.9.9 - - [23/May/2014:08:37:27 +1000] "GET /times HTTP/1.1" 200 1550 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0"

152.91.9.9 - - [23/May/2014:08:37:39 +1000] "GET /admin/ HTTP/1.1" 200 1446 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0"

WSGI file contains nothing unusual:

import os
import sys

sys.path.append('/home/paul/src/awma-apache/')
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "internationalguidelines.settings_prod")

from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

I was trying to do some tricky stuff with virtualenv initially, but I still see the problem with the
config stripped back very simple, as described above.

P.

[Spaceman Paul]

I've worked around it by creating another A-record and pointing each application to the server root of the respective
virtual host, but this should not be necessary.

[Spaceman Paul]

Playing around some more, and inserting some trace statements in the django code, I can see
(for the example ^times$ pattern):

1) When WSGIScriptAlias is the server root:

The RegexURLResolver.resolve(self,path) method (in django.core.urlresolvers.py) is called three times,
each time with path="/times" and each time it successfully resolves at the "^times$" pattern.

2) When WSGIScriptAlias is not server root (i.e. /awma):

The RegexURLResolver.resolve(self,path) method (in django.core.urlresolvers.py) is called four times:

a) The first two times it is called with path="/times" and successfully resolves at the "^times$" pattern.
b) The third time it is called with path="/awma/times" - not surprisingly it does not resolve.
c) The fourth time is is called with path="awma/times" - this fails too.

It looks like the fourth call is made from within the third call - it's the call for the admin url include.

Overall result is a 404.

This is looking at the 2.4.13 codebase - although the method is basically the same in 2.6.5 and I
see the same behaviour there.

Is this a bug?  Surely I can't be the only person using WSGI with a non-root mount point.

P.

[Spaceman Paul]

Ugh nevermind.

Yes it's a bug - but in my code.  I'll figure it out.

[Spaceman Paul]

In case anyone else ends up with same problem, I was using request.path instead of request.path_info.

P.

On Friday, 23 May 2014 14:58:11 UTC+10, Spaceman Paul wrote: