Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <007c01c1b3d1$46714650$94c0b0d0@v505>
From: "William A. Rowe, Jr." <wrowe@covalent.net>
To: <dev@httpd.apache.org>
References: <200202121332.IAA27467@web.turner.com>
Subject: Re: 2.0.31 include and expires
Date: Tue, 12 Feb 2002 08:25:19 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

This was a key reason for my mod_dir patch that broke Brian's request, below.
This is also a mod_negotiation bug, we simply hadn't realized it yet.

From: "Brian Akins" <bakins@web.turner.com>
Sent: Tuesday, February 12, 2002 7:35 AM


> I've been playing with 2.0.31 and I've noticed something strange.  All of our 
> .html and .htm files are server-parsed and should also have an expire time 
> set.  ...
>
> A request for http://foo/ does not get parsed or get expiry headers set.  
> However, http://foo/index.hml works as expected.
> 
> This just doesn't seem right,  I have been toying with porting some of our 
> modules to Apache 2, but I obviously don't understand what's going here.  Why 
> isn't http://foo/ recognized as text/html?

No, it is not right, and yes - http://foo/ should be appropriately recognized.
We are evidently not moving enough info from the subreq to the parent request
in ap_fast_internal_redirect(); at least the filter chain, and some meta data 
related to the expires date....

Set{Input|Output}Filter[ByType] all set up filters in the typemap hook.  It
appears we did not copy these from the internal DefaultIndex subrequest back 
into the main request - we needed to.  I'm not certain where the expires date
is cached; the output headers?  In any case, perhaps the entire headers need to 
slide from the sub request to the main request.

A better answer is possibly to drop ap_internal_fast_redirect altogether (and
changing both mod_dir and mod_negotiation to never use the beast again) - that
includes Apache 1.3.  This code, while normalized, is not much better than
it was playing 1.3 negotiation.  The code has been a source of vulnerabilities
which I fixed, and other 'bugs' - most of which I'd fixed.  Who knows how many
more lurk, waiting to be 'discovered'.

Axe ap_internal_fast_redirect()?  Are any 3rd party modules taking advantage
of this hack from negotiation?

Bill