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: "'Greg Stein'" <gstein@lyra.org>,
	<dev@httpd.apache.org>
Subject: RE: 2.0.34 - erratic behavior with autoindexes  ( I believe the bug
 is analyzed in this message)
Date: Tue, 2 Apr 2002 16:11:18 -0800
Organization: Covalent Technologies
Message-ID: <003d01c1daa4$13b5d560$3e00000a@KOJ>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <20020402160711.G30017@lyra.org>
Importance: Normal

> > > > We are talking about the main request flushing its
> > > > buffers before it runs the request.
> > >
> > > Um. How'd the buffers get filled before running the request?
> >
> > The problem is that the main request generates content, and that
goes
> > into the OLD_WRITE filter buffer.  Then it creates a sub-request.
If
> > the sub-request doesn't use the same OLD_WRITE instance, you have a
> > major bug.
> 
> Huh? No...
> 
> Let's say the main req created an OLD_WRITE and put some content in
there.
> Next, the sub-request inserts its own OLD_WRITE instance (which it
won't,
> but let's run with this). The subreq then starts jamming content into
its
> own OLD_WRITE. When the subreq goes away, an EOS will hit the
OLD_WRITE in
> the sub_req, which will flush the content on up to the main request.
The
> main request's OLD_WRITE will prepend its data, and continue flushing
the
> data down the pipe.
> 
> Now, the SUBREQ filter actually intercepts that EOS, but it does pass
the
> data along. The OLD_WRITEs are emptying their buffers properly.
> 
> Now, the real situation is that a second OLD_WRITE won't be added.
When
> you
> call ap_r*(), it will scan the entire chain looking for an existing
> OLD_WRITE to be present. If it is there, then another won't be added.
If
> the
> filter is not at the top, it won't be used.
> 
> And lastly, remember the ordering of the filters. Even if the subreq
> inserts
> stuff, the OLD_WRITE should always remain at the "top".

No.  The filters are ordered on a per-request basis, so even if the main
request has the OLD_WRITE filter, sub-request filters won't be in filter
chain below that OLD_WRITE filter.

A graphic might help:

If I have a request with the filter chain:

OLD_WRITE  -> INCLUDES  -> byterange  -> C-L  -> CORE

There are two ways to create the sub-request.

1)  Point the sub-request at the filter stack, which should produce:
(THIS IS WHERE THE BUG IS HAPPENING!!!!!!!)

SUB_REQ_EOS  -> OLD_WRITE  -> INCLUDES  -> byterange  -> C-L  -> CORE

Any other filters for the sub-request will be inserted before the
SUB_REQ_EOS filter.

However, what is happening instead, is that filters are being added
like:

OLD_WRITE  -> SUB_REQ_EOS  -> INCLUDES -> byterange  -> C-L  -> CORE

The problem with this, is that the sub-request->output_filters pointer
is pointing to SUB_REQ_EOS, not to OLD_WRITE, which means that the
OLD_WRITE filter is being missed entirely for the sub-request.

2)  Don't point the sub-request at the filter stack:  (All RESOURCE and
CONTENT_SET filters are removed from the sub-request)

SUB_REQ_EOS  ->  byterange  -> C-L  -> CORE

I hope that explains it.  I am hoping to look at this in a lot more
detail later tonight.

Ryan