> Try dumping out the contents of request.subprocess_env and see if > there are any REDIRECT_? values you can check.
I checked, and found no such values. The remaining workarounds are getting too complicated for my liking. I guess I'll rearrange the site to avoid using *AliasMatch, or maybe give up on MoinMoin. I'd get rid of mod_python if I could, but I need apache-openid (or something like it). If there was an alternative to mod_python that allowed an OpenID implementation in python (intercept arbitrary apache requests, perform conditional redirects, etc.) I'd gladly port apache-openid to it. Sadly, I don't think mod_wsgi's auth hooks are enough to make this work. Thanks for all the suggestions, Graham. Cheers, Forest On Wed, Oct 12, 2011 at 14:10, Graham Dumpleton <[email protected]> wrote: > On 13 October 2011 04:49, Forest <[email protected]> wrote: >> 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? > > There are still lots of known documented bugs in mod_python and not > surprised if request.main causes a problem. That specific ability was > always dodgy and I remember making some fixes for it to avoid mixing > Python objects across Python sub interpreters. Code could still be > wrong of Apache has changed in the mean time to make it not work. > > You could try forcing: > > PythonInterpreter main > > and see if that helps. > >> (If so, I wonder if there's an alternative way for a >> mod_python handler to detect a subrequest.) > > Try dumping out the contents of request.subprocess_env and see if > there are any REDIRECT_? values you can check. > > If you had mod_rewrite available you could also do something like have > a rule which checks for IS_SUBREQ and then set an ENV variable which > can be checked. > > You might just send me the access handler code and I can think whether > there is any way you could do it another way. > > Graham > >> 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. >> >> > > -- > 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. > > -- 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.
