Thanks for all the suggestions, Graham. As you guessed, my apache access handler runs under mod_python. (A requirement of apache-mod- python.) I can modify it if it's misbehaving, of course.
To that end, I've just spent some time playing with my mod_python accesshandler, and found something interesting. The very first action it takes is: "if request.main: return apache.DECLINED". The idea here is to do nothing for sub-requests. When I remove that bit of code, using WSGIScriptAliasMatch no longer triggers the recursion/segfault. Odd. When I add a single line containing only "request.main" back into the code, using WSGIScriptAliasMatch once again triggers the recursion/ segfault. Looks like simply reading the value of "request.main" in a mod_python access handler causes a crash when WSGIScriptAliasMatch is in play. I'm pretty sure python code should be unable to crash the interpreter or apache. Could this be a bug in mod_python, or possibly in mod_wsgi? (If so, I wonder if there's an alternative way for a mod_python handler to detect a subrequest.) Putting that issue aside for a moment, and leaving all "request.main" references commented out in the mod_python access handler to avoid the crash, I found that this syntax yields the SCRIPT_NAME and PATH_INFO values I've been seeking: WSGIScriptAliasMatch ^/(?!auth|sitepage) /var/moin/apidoc/server/ moin.wsgi This syntax started working as well: Alias /auth /path/to/apache-openid/stuff Alias /sitepage /path/to/other/stuff WSGIScriptAlias / /var/moin/apidoc/server/moin.wsgi In both cases, SCRIPT_NAME is always '' and PATH_INFO is the full path from the requested URL. So, this is a lot of progress. I guess now I need to figure out why WSGIScriptAliasMatch turns mod_python's request.main field into a land mine that explodes when read. On Oct 12, 2:18 am, Graham Dumpleton <[email protected]> wrote: > I do some looking at WSGIScriptAliasMatch, but can we go back to the > original reason for doing this. > > What needs to be served up when access the URLs: > > /auth > /sitepage > > Overlapping sets of URLs can be handled in various ways and AliasMatch > directives should always be the last option. > > If you have: > > WSGIScriptAlias / /var/moin/apidoc/server/moin.wsgi > > and need a different WSGI application at the other URLs, you would use: > > WSGIScriptAlias /auth /some/path/auth.wsgi > WSGIScriptAlias /sitepage /some/path/sitepage.wsgi > > WSGIScriptAlias / /var/moin/apidoc/server/moin.wsgi > > If the URLs are for static resources or dynamic scripts the handler of > which is specified by AddHandler, then use Alias instead to override: > > Alias /auth /some/path/auth.cgi > Alias /sitepage /some/path/sitepage.html > > WSGIScriptAlias / /var/moin/apidoc/server/moin.wsgi > > Another alternative is to do as described in: > > http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines#The_Apa... > > and have appropriate config including: > > AddHandler wsgi-script .wsgi > > with rewrite rule of: > > RewriteEngine On > RewriteCond %{REQUEST_FILENAME} !-f > RewriteRule ^(.*)$ /site.wsgi/$1 [QSA,PT,L] > > What happens here is that Apache files exact resource in directory it > will use that, otherwise it falls back to pushing everything through > site.wsgi application. > > So there are easier alternatives to using WSGIScriptAliasMatch or > AliasMatch, but am unclear of what this python-apache-openid is. It > sounds a bit like it might be dependent on mod_python which is asking > for trouble. What is the configuration in the Apache configuration for > that package and how is it triggered? > > Graham > > On 12 October 2011 19:09, Forest <[email protected]> wrote: > > > > > > > > > I did. (See below.) > > > On Oct 12, 1:06 am, Graham Dumpleton <[email protected]> > > wrote: > >> Did you try the same pattern I gave you for WSGIScriptAliasMatch with > >> AliasMatch. Ie., no .* and the $1 substitution? > > >> Graham > > >> On 12 October 2011 18:00, Forest <[email protected]> wrote: > > >> > mod_rewrite isn't even enabled on this server. > > >> > I do have an access handler (Ubuntu's python-apache-openid) configured > >> > in my <Directory /var/moin/apidoc/server> section. It's designed to > >> > redirect to /auth/+login if a cookie isn't set, which is why I'm > >> > excluding /auth in my AliasMatch regex. Removing the access handler > >> > gets rid of the infinite subrequest / segfault when I use > >> > WSGIScriptAliasMatch, but since AliasMatch works fine with the access > >> > handler enabled, it didn't seem worth my time to debug > >> > WSGIScriptAliasMatch. That's why I'm trying to get SCRIPT_NAME and > >> > PATH_INFO to be set correctly when I use AliasMatch. > > >> > Of course, if you know how to get WSGIScriptAliasMatch to avoid the > >> > segfault just as AliasMatch does, I guess that might work just as > >> > well. > > >> > On Oct 11, 11:35 pm, Graham Dumpleton <[email protected]> > >> > wrote: > >> >> Do you have any separate mod_rewrite rules in your Apache configuration? > > >> >> WSGIScriptAliasMatch itself should not trigger any internal > >> >> redirections that I know of. > > >> >> Graham > > >> >> On 12 October 2011 17:09, Forest Wilkinson <[email protected]> wrote: > > >> >> > When I use WSGIScriptAliasMatch, even with the arguments you > >> >> > suggested, I get a ton of these errors in apache's error.log: > > >> >> > Request exceeded the limit of 10 subrequest nesting levels due to > >> >> > probable confguration error. Use 'LimitInternalRecursion' to increase > >> >> > the limit if necessary. Use 'LogLevel debug' to get a backtrace. > > >> >> > Followed by this error: > > >> >> > child pid 12345 exit signal Segmentation fault (11) > > >> >> > When I use this: > > >> >> > AliasMatch ^/(?!auth|sitepage) /var/moin/apidoc/server/moin.wsgi/$1 > > >> >> > I get those same errors, as if I had used WSGIScriptAliasMatch. > > >> >> > When I use this: > > >> >> > AliasMatch ^/(?!auth|sitepage) /var/moin/apidoc/server/moin.wsgi > > >> >> > The errors go away, but SCRIPT_NAME and PATH_INFO are wrong, as in my > >> >> > original post. > > >> >> > On Tue, Oct 11, 2011 at 23:00, Graham Dumpleton > >> >> > <[email protected]> wrote: > >> >> >> On 12 October 2011 16:47, Forest Wilkinson <[email protected]> wrote: > >> >> >>> AliasMatch ^/(?!auth|sitepage).* /var/moin/apidoc/server/moin.wsgi > > >> >> >>> WSGIScriptAliasMatch ^/(?!auth|sitepage).* > >> >> >>> /var/moin/apidoc/server/moin.wsgi > > >> >> >> What happens if you use: > > >> >> >> WSGIScriptAliasMatch ^/(?!auth|sitepage) > >> >> >> /var/moin/apidoc/server/moin.wsgi/$1 > > >> >> >> Don't have .* on left hand side. It will match leading path. > > >> >> >> Can't remember if /$1 will be required to get SCRIPT_NAME to be > >> >> >> empty. > > >> >> >> Graham > > >> >> >>> On Tue, Oct 11, 2011 at 22:39, Graham Dumpleton > >> >> >>> <[email protected]> wrote: > >> >> >>>> Provide both the WSGIScriptAliasMatch and AliasMatch directive > >> >> >>>> lines you used. > > >> >> >>>> Graham > > >> >> >>>> On 12 October 2011 16:29, Forest <[email protected]> wrote: > >> >> >>>>> Hi, all. > > >> >> >>>>> I believe I should be able to use apache's AliasMatch directive > >> >> >>>>> instead of WSGIScriptAlias, so long as I also use SetHandler wsgi- > >> >> >>>>> script and Options +ExecCGI in my <Directory> section. This is > >> >> >>>>> mostly > >> >> >>>>> working for me, except that SCRIPT_NAME is being set to the entire > >> >> >>>>> path of each request's URL, and PATH_INFO is always empty. > >> >> >>>>> Unfortunately, this causes MoinMoin to misbehave. > > >> >> >>>>> When I use WSGIScriptAlias, SCRIPT_NAME and PATH_INFO are set > >> >> >>>>> correctly. > > >> >> >>>>> What must I do to get modwsgi to set SCRIPT_NAME and PATH_INFO > >> >> >>>>> correctly when using AliasMatch? > > >> >> >>>>> (Incidentally, I'm using AliasMatch in order to route all paths > >> >> >>>>> except > >> >> >>>>> a couple of specific ones to MoinMoin's wsgi application. I tried > >> >> >>>>> WSGIScriptAliasMatch with the same regular expression, but this > >> >> >>>>> caused > >> >> >>>>> apache to fail with recursion errors and segmentation faults in > >> >> >>>>> the > >> >> >>>>> error log.) > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
