On Mar 5, 8:26 am, Matt <[EMAIL PROTECTED]> wrote:
> > Also, you aren't mounting your application at the root of the web
> > server but a sub URL, this means that you have to use a WSGI wrapper
> > around Django entry point and have to include the mount point path in
> > the URLs in urls.py. This is documented in [1], but you don't seem to
> > use the wrapper in your script file.
>
> I've been trying to avoid having to modify my url_patterns in a
> mounting-specific way, so I opted not to use the workaround from
> #2407. It was my understanding that this fix needs to be employed if
> you're trying to host multiple Django sites under a single
> VirtualHost. With the exception of the TypeError in my original post,
> everything works as it should - Django essentially sees a cropped
> version of the url in the address bar (i.e. with /my_app/foo removed),
> so url_patterns shouldn't care that there's a url prefix.
>
> Here is my urls.py:
> -----
> urlpatterns = patterns('',
>     (r'^/?$',
> direct_to_template, {'template': 'viewer.html'}),
>     (r'^upload/?$',                              views.upload),
>
>     (r'^accounts/login/$',                    login,
> {'template_name': 'login.html'}),
>     (r'^accounts/logout/$',                  logout,
> {'next_page': 'accounts/login/'}),
>
>     (r'^admin/',
> include('django.contrib.admin.urls')),
> )
> -----
>
> I don't fully understand the SCRIPT_NAME problem, but I can surmise
> why I'm getting the TypeError: mod_wsgi removes the /my_app/foo prefix
> from the url in the address bar and feeds the rest to Django - in the
> first url_pattern above, that would be an empty string. My guess is
> that mod_wsgi is sending it None instead, causing the exception.

The string shouldn't ever be pass as None, so must be something else.

I believe the reason for the SCRIPT_NAME fiddle is that when you use
APIs within Django to construct a full URL, eg., for doing a redirect,
or perhaps for referencing static files, it will be wrong without the
fiddle. I don't use Django, so don't the specific functions that might
be the issue there. From memory I believe the problems show up quite
readily if you enable the admin interface. Some embedded URLs get sent
back as /admin instead of /my_app/foo/admin.

> Simply matching something other than the empty string would avoid this
> problem, but if my surmising above is correct, is that a bug in
> mod_wsgi?

Don't believe so.

Graham

> Many thanks,
> Matt.
>
> > Hopefully the above helps, but also check out Apache documentation for
> > Alias directive.
>
> On Mar 3, 6:14 pm, Graham Dumpleton <[EMAIL PROTECTED]>
> wrote:
>
>
>
>
>
> > On Mar 4, 4:19 am, Matt <[EMAIL PROTECTED]> wrote:
>
> > > Hello group,
>
> > > I'm having some problems understanding the URL setup for mod_wsgi. The
> > > documentation at [1] is excellent, but all of the examples of the
> > > Apache configuration have a trailing slash appended to the Alias.
>
> > Did you also read:
>
> >  http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines
>
> > This has other examples including one which shows mounting at sub URL.
>
> > Also, are you talking about Alias directive used to map your static
> > files, or WSGIScriptAlias directive and the Django application URLs
> > itself?
>
> > > In my experience, that means that /my_app/foo results in a 404. All of my
> > > url_patterns have an optional trailing slash, so my assumption is that
> > > this is an Apache pattern-matching issue.
>
> > Maybe, maybe not.
>
> > Also, you aren't mounting your application at the root of the web
> > server but a sub URL, this means that you have to use a WSGI wrapper
> > around Django entry point and have to include the mount point path in
> > the URLs in urls.py. This is documented in [1], but you don't seem to
> > use the wrapper in your script file.
>
> > > Even worse, when I browse to /my_app/foo/, I get a TypeError. Here's
> > > the traceback:
>
> > > -----
> > > File "C:\Python25\lib\site-packages\django\core\handlers\base.py" in
> > > get_response
> > >   73.             callback, callback_args, callback_kwargs =
> > > resolver.resolve(request.path)
>
> > > Exception Type: TypeError at
> > > Exception Value: 'NoneType' object is not iterable
> > > -----
>
> > > I get the best results by removing the trailing slash from the Apache
> > > configuration. Then, the page loads correctly at /my_app/foo/, but I
> > > get the same TypeError at /my_app/foo (without the slash).
>
> > Post urls.py file as that is where this problem most likely lies.
>
> > > Config files are below. The platform is Windows with 0.97-pre-SVN-7190
> > > and Apache 2.2.6.
>
> > > httpd.conf:
> > > -----
> > > Alias /my_app/foo/media "d:/www/media/foo/"
>
> > Recommended that you use:
>
> >   Alias /my_app/foo/media/ "d:/www/media/foo/"
>
> > ie., trailing slash on LHS required. That way if someone tries to
> > access '/my_app/foo/media' they will get 404. See:
>
> >  http://httpd.apache.org/docs/2.2/mod/mod_alias.html#alias
>
> > for how trailing slashes affect Alias directive.
>
> > > <Directory "d:/www/media">
> > > Order allow,deny
> > > Options Indexes FollowSymLinks
>
> > There is no good reason for turning on indexing except if debugging
> > things.
>
> > > Allow from all
> > > IndexOptions FancyIndexing
> > > </Directory>
>
> > > WSGIScriptAlias /my_app/foo "d:/Data/webdev/apache/foo.wsgi"
>
> > This is correct, but means that urls.py should prefix stuff with
> > '^my_app/foo'. You don't post your urls.py file so can't see if that
> > is what you are doing.
>
> > Not having a trailing slash on left hand side means that Django must
> > properly handle a request without the trailing slash and force a
> > redirect to the URL with the trailing slash added. I believe this is
> > the default behaviour.
>
> > If you use:
>
> >   WSGIScriptAlias /my_app/foo/ "d:/Data/webdev/apache/foo.wsgi"
>
> > then only the exact URL '/my_app/foo/' would get passed to the
> > application and a URL with anything else on the end would be rejected
> > with a 404 error.
>
> > If for some reason you need the trailing slash on LHS and for all URLs
> > to be passed through, you would need to use:
>
> >   WSGIScriptAlias /my_app/foo/ "d:/Data/webdev/apache/foo.wsgi/"
>
> > Accessing '/my_app/foo' in this case would yield a 404.
>
> > In general, for WSGIScriptAlias, if the RHS is a script file, don't
> > have a trailing slash on LHS, except for the special case where
> > mounted at root of server and thus the LHS is just '/'.
>
> > If the RHS is a directory and you want an automatic mapping for many
> > script files in the one directory, both LHS and RHS must have a
> > trailing slash.
>
> > > <Directory "d:/Data/webdev/apache">
> > > Allow from all
> > > </Directory>
> > > -----
>
> > > foo.wsgi:
> > > -----
> > > import os, sys
>
> > > #Calculate the path based on the location of the WSGI script.
> > > apache_configuration= os.path.dirname(__file__)
> > > project = os.path.dirname(apache_configuration)
> > > workspace = os.path.dirname(project)
> > > sys.path.append(workspace)
>
> > > #Add the path to 3rd party django application and to django itself.
> > > sys.path.append('C:\\Python25\\Lib\\site-packages')
> > > sys.path.append('D:\\Data\\webdev\\projects\\foo')
>
> > > os.environ['DJANGO_SETTINGS_MODULE'] = 'src.settings'
> > > import django.core.handlers.wsgi
> > > application = django.core.handlers.wsgi.WSGIHandler()
>
> > As per [1], you aren't doing:
>
> >   _application = django.core.handlers.wsgi.WSGIHandler()
>
> >   def application(environ, start_response):
> >       environ['PATH_INFO'] = environ['SCRIPT_NAME'] +
> > environ['PATH_INFO']
> >       return _application(environ, start_response)
>
> > > Can someone with a better understanding of mod_wsgi can explain why
> > > the examples at [1] include trailing slashes on aliases? Does anyone
> > > have any insight on the TypeError I'm experiencing?
>
> > Hopefully the above helps, but also check out Apache documentation for
> > Alias directive.
>
> > Graham
>
> > > Many thanks,
> > > Matt.
>
> > > [1]http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to