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 at 
http://groups.google.com/group/modwsgi?hl=en.

Reply via email to