Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <056401c152c9$067109a0$96c0b0d0@roweclan.net>
From: "William A. Rowe, Jr." <wrowe@covalent.net>
To: <dev@httpd.apache.org>
References: <20011009192919.69808.qmail@icarus.apache.org>
 <039b01c151c4$92ace9d0$93c0b0d0@roweclan.net> <3BC61B40.9F8BABFF@remulak.net>
Subject: Re: cvs commit: httpd-2.0 STATUS
Date: Thu, 11 Oct 2001 21:53:05 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

From: "Greg Ames" <gregames@remulak.net>
Sent: Thursday, October 11, 2001 5:20 PM


> "William A. Rowe, Jr." wrote:
> > 
> > Let me make this _perfectly_clear_, the only reason .asis worked before is that
> > _every_ filename extension worked before.  .bak, .old, didn't matter.  Everything
> > was served, and many users (>100) complained that there was some 'bug' in their
> > apache installation.  You may call that a misconfiguration, but our users disagree.
> 
> I agree, that sounds pretty bogus to me also.  I do appreciate all your
> efforts in resolving it.
> 
> How about this: we keep track of the extensions added by AddHandler &
> Add*Filter, and allow them to match, along with the conventional mime
> type extensions.  I believe the code I committed is doing that already,
> right?  

It did, and I vetoed that patch.

I then added the MultiviewsMatch directive allowing three behaviors;

MultiviewsMatch All            {The old, bogus 1.3 behavior}
MultiviewsMatch NegotiatedOnly {A 'pure' implementation}
MultiviewsMatch [Handlers] [Filters]  {your desired behaviors}

> If you think about the steps involved in moving the
> /www.apache.org/search.html link, that works out rather smoothly without
> any new externals, or confusion:
> 
> 1. create and test the /search.apache.org/ site and vhost definitions.
> No ambiguity so far.
> 2. create the /www/www.apache.org/search.html.asis file to redirect
> people with old links.  search.html still exists in the same directory,
> so there are ambiguous matches at this instant.
> 3. delete the search.html file.  no more ambiguity.
> 
> The beauty of it is that users are able to get something back at their
> browsers all through this process.  During step 2, we resolve the
> ambiguity by picking the smallest file.  Fine; the user didn't get a 404
> in this window.  A few seconds later we complete step 3 and users
> definitely get the new stuff.
> 
> If I were the admin doing this and didn't know any better, I might have
> renamed search.html to search.html.hide or .old or something in step 3,
> just because I've been burned too many times by deleting stuff
> altogether.  I wouldn't have been very happy if Apache served it
> after I tried to hide it, no matter what size it was.

But there is a deeper reason not to rely on anything but the truly 
negotated types ... if you 'forget' to update your languages, charsets,
or whatnot, folks were getting .zh documents without the language
associated!!!  It's really hokey to debug.

So the purely negotated behavior is the default.  You can now back down
to either a 'loose' behavior of also matching on handlers/filters (which
are _NOT_ negotiated mime variables, they are just handled in the same
module) or you can play really fast and loose, and just serve any files
matching request*.  The choice is the administrators, we just provide
sanity defaults.

I'll be updating both docs over the weekend.

Bill