Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Reply-To: <rbb@covalent.net>
From: "Ryan Bloom" <rbb@covalent.net>
To: <dev@httpd.apache.org>
Subject: RE: Baffled by the negotation fix...
Date: Fri, 1 Mar 2002 16:50:16 -0800
Organization: Covalent Technologies
Message-ID: <01af01c1c184$382d20d0$7f00000a@KOJ>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <20020301223333.GE24710@ebuilt.com>

> On Fri, Mar 01, 2002 at 03:12:27PM -0600, William A. Rowe, Jr. wrote:
> > I believe the attached .patch file should resolve our issues with
the
> > subrequest
> > negotiation.  Essentially, we want the sub request to build a new
filter
> > chain if
> > we plan on using the subrequest as a 'fast internal redirect'.
> >
> > This patch does just that, when we fast redirect, we replace the
> original
> > request
> > filters with the new request filters.  In preparing the request, we
go
> back
> > to our
> > favorite r->connection filters to start, when we are making the
> subrequest
> > with
> > a NULL next_filter.
> >
> > But the patch is broken.  Free beer at ApacheCon 2002 to the first
> hacker
> > who
> > untangles the misbehavior that fouls up this patch.  Make that hard
> stuff if
> > you
> > discover it's a simple bug in my patch :)
> >
> > One hint.  I think our whole "Either Connection or Request" idea of
> filters
> > is
> > borked.  It really seems that "Either Connection or Protocol or
Body" is
> a
> > much
> > better model - this bug seems to prove that once again.  I think we
> really
> > wanted
> > to grab r->http_input_filters and r->protocol_output_filters when we
set
> up
> > the
> > subreq of next_filter==NULL.  But there doesn't appear to be such a
> thing.
> 
> Yup, you're right.  We need to add protocol-specific filters that
> can be arbitrarily reset.  Hint: this is just what reset_filters
> does, but its static.  Notice that we do this when we are about
> to serve an HTTP error - the same concept of a subreq applies to
> the error condition.
> 
> To prove that, this patch works for me.  So, what I think we should
> do is add a protocol hook that says, "add all of your required
> filters if this is your protocol."  How does that sound?  -- justin

I don't understand how this is working.  The original code from Will
came from a discussion that he and I had over the phone.  My question is
how were the protocol specific filters removed in this case?

Oh, damn, the problem is that these filters are request specific instead
of connection specific.  What we really need, is a filter type that is
request specific, but that isn't specifically tied to the request.
Basically another field in the request_rec, which would store all store
all HTTP_HEADER filters.  That way, they wouldn't be lost for
sub-requests and internal redirects.

Ryan