Here is a summary of what one would expect from WSGIScriptAliasMatch: WSGIScriptAliasMatch ^/suburl /Library/WebServer/Sites/hello-1/htdocs/environ.wsgi
URL: /suburl SCRIPT_NAME: /suburl PATH_INFO: URL: /suburl/abcd SCRIPT_NAME: /suburl PATH_INFO: /abcd For: WSGIScriptAliasMatch ^/(suburl) /Library/WebServer/Sites/hello-1/htdocs/environ.wsgi Same as above. For: WSGIScriptAliasMatch ^/(suburl)(/.*)? /Library/WebServer/Sites/hello-1/htdocs/environ.wsgi Bad idea this one as every URL will be unique SCRIPT_NAME. URL: /suburl SCRIPT_NAME: /suburl PATH_INFO: URL: /suburl/abcd SCRIPT_NAME: /suburl/abcd PATH_INFO: URL: /suburl/abcdefgh SCRIPT_NAME: /suburl/abcdefgh PATH_INFO: Should change to: WSGIScriptAliasMatch ^/(suburl)(/.*)? /Library/WebServer/Sites/hello-1/htdocs/environ.wsgi/$2 This is what I should have given you before. It is second sub pattern should be substituting. URL: /suburl SCRIPT_NAME: /suburl PATH_INFO: URL: /suburl/abcd SCRIPT_NAME: /suburl PATH_INFO: /abcd This assumes you want /suburl to be mount point, if you still wanted it to appear at root of site would use: WSGIScriptAliasMatch ^(/(suburl)) /Library/WebServer/Sites/hello-1/htdocs/environ.wsgi$1 URL: /suburl SCRIPT_NAME: PATH_INFO: /suburl URL: /suburl/abcd SCRIPT_NAME: PATH_INFO: /suburl/abcd Note that have only bracketed the 'suburl' bit with it in mind that you would have: WSGIScriptAliasMatch ^(/(suburl|alt-suburl)) /Library/WebServer/Sites/hello-1/htdocs/environ.wsgi$1 URL: /suburl SCRIPT_NAME: PATH_INFO: /suburl URL: /suburl/abcd SCRIPT_NAME: PATH_INFO: /suburl/abcd URL: /alt-suburl SCRIPT_NAME: PATH_INFO: /alt-suburl URL: /alt-suburl/abcd SCRIPT_NAME: PATH_INFO: /alt-suburl/abcd Now lets try that scary negation pattern. WSGIScriptAliasMatch ^(/(?!suburl|alt-suburl)) /Library/WebServer/Sites/hello-1/htdocs/environ.wsgi$1 URL: /suburl Not found. URL: /alt-suburl Not found. URL: /abcd SCRIPT_NAME: PATH_INFO: /abcd Not sure it makes sense to have exclusion but mounting at sub url so left as exercise for the reader. Note that the best way of playing with this to work out what does what is to point at environ.wsgi, which is the script given in: http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Displaying_Request_Environment Now everything as far as I can tell is behaving correctly. If this other package is using mod_python and PythonAccessHandler then all sorts of crazy things could happen because often such mod_python handlers weren't written very well and certainly not so as to coexist properly with other stuff. Graham On 12 October 2011 20:18, 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_Apache_Alias_Directive > > 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 >>> >> >>>>> athttp://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 >>> >> >>>> athttp://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 >>> >> >>> athttp://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 >>> >> >> athttp://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 >>> >> > athttp://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 >>> > athttp://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.
