Apache option MultiViews interfering with mod_perl

[André Warnier <aw...@ice-sa.com>]

Hi.

It is quite certain that the basic reason for my troubles is my own lack of expertise, but 
I suppose that others may stumble into the same issue at some point, and this may help 
them avoid the loss of time involved.

Basically, I had an Apache (2.2) configuration section as follows :

<Location /login>
   PerlAccessHandler my::module->access
   PerlFixupHandler my::module->fixup
   SetHandler modperl
   PerlResponseHandler my::module->login
   PerlSetVar my_login_form "/login.html"
</Location>

As you can probably guess, this is part of a self-written authentication mechanism derived 
from Apache::AuthCookie, and the login form that is used is the document at 
(DocumentRoot)/login.html.

Now this has worked fine on dozens of servers so far, for several years.

But then unexpectedly on this new similar webserver that I just set up, it didn't work 
anymore, in a quite peculiar way :

- the above PerlAccessHandler was run fine, and logged everything as normally
- but neither the PerlFixupHandler nor the PerlResponseHandler were being run, without any 
error or trace at all in the logs.
Instead, all I got was the login document in the browser, but in a way that showed that it 
was delivered straight from the disk, without going through the response-handler at all 
(which it normally does).

It was also quite puzzling because how could it respond with "/login.html" when I 
requested "/login", and how could it nevertheless show a POST to "/login", with a response 
code 200 OK in the access log.
Did Apache somehow start behaving like hateful end-user software, divining what was good 
for me, instead of what I explicitly said I wanted ?

To make a long story shorter (by 2 days), I finally realised that it was because in this 
particular server, there was a unique coincidence of two elements :

- the DocumentRoot directory of the server had a "Options MultiViews" added to it
- my login document was "/login.html"

And why the problem happened was this stanza in the Apache on-line documentation of the 
Options directive (and/or mod_negociation) :

quote

MultiViews

A MultiViews search is enabled by the MultiViews Options. If the server receives a request 
for /some/dir/foo and /some/dir/foo does not exist, then the server reads the directory 
looking for all files named foo.*, and effectively fakes up a type map which names all 
those files, assigning them the same media types and content-encodings it would have if 
the client had asked for one of them by name. It then chooses the best match to the client's..

unquote

So what happened here was :
- the PerlAccessHandler was run normally, as it happens quite early in the Apache cycle, 
before Apache even starts to map the URL to a file on disk
- then somewhere mod_negociation takes over.
It looks at the requested URL (/login), and does not find a corresponding directory 
"(DocumentRoot)/login".
So then, it looks in the directory "/", trying to find anything that looks like "login.*".
In this case, it finds "/login.html".
So it sets things up to return "/login.html" as the response. Predictable and fair enough, 
one could say.
Except that in the process it *disables* the other configuration lines which should have 
invoked the fixup handler and mod_perl as the response handler, and these are never run.
Instead, it seemingly runs the Apache default handler, which just returns the file.

Removing the MultiViews option made things get back to normal.
Changing the name of the login form to something not matching "/login" so closely also 
does the trick.

But it took me close to two days to figure this out, mainly because I have dozens of other 
servers which have exactly the same <Location> section and are doing fine, and I just 
never realised that this MultiViews Option, inherited from way back up there in the 
configuration, could have such a drastic effect.

HTH someone some day.