Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <09a101c1717b$679727c0$94c0b0d0@v505>
From: "William A. Rowe, Jr." <wrowe@covalent.net>
To: <dev@httpd.apache.org>
References: <20011119193821.T20209@ebuilt.com>
 <096a01c17177$8c0f3ba0$94c0b0d0@v505> <20011119201932.V20209@ebuilt.com>
Subject: Re: Remove input filtering as a showstopper?
Date: Mon, 19 Nov 2001 22:25:35 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

From: "Justin Erenkrantz" <jerenkrantz@ebuilt.com>
Sent: Monday, November 19, 2001 10:19 PM


> On Mon, Nov 19, 2001 at 09:57:50PM -0600, William A. Rowe, Jr. wrote:
> 
> > ap_getline needs to behave as it once did, even if that means
> > calling the filter stack again with blocking for more data, or
> > pushing back the data where a subsequent call to ap_getline or
> > the block read can get at the overrun (of course this implies
> > pushback.)  If I'm confused, it's because I don't understand the 
> > ap_getline issue any more than you understood the filtering issue 
> > called semantics ;)
> 
> The root problem with ap_getline is that it peeks ahead to see
> if there is a \t or space at the beginning of the line - this
> indicates a MIME-continuation line.  If it isn't a whitespace,
> we need to set it aside and come back later and read it.  
> Otherwise, we read that line and then do the MIME-continuation
> check again.

Thank you for taking the time to explain this issue (now I grok :)

> I am not comfortable enough with the design aspects of filters to 
> go further than stating that I don't like pushback.  Roy and Greg 
> are the ones who have seem to thought this concept through the 
> most and have a clear picture.  So, I'll state my questions from 
> the STATUS entry and step aside:
> 
> [ pushback model ]
> 
> - How do we handle stuff like mod_ssl - we can't "unread" data.  So, 
>   do we have two brigades for each filter?  An in brigade and a 
>   returned brigade?  That seems messy.

No need.  95% of filters don't need to set aside input if they can
push it back (basically, split the bucket, consume the first part of
the data, and consume the rest later, if they are even there to be
the consumer on the next call ;)

If folks rather, we can simply call this a consumer model, where the
callee can consume all or part of the prior brigade, and the provider
hangs on (to a possibly emptied brigade) and continues to fill this
same (at least partially emptied) brigade on subsequent calls.

> [ Non-pushback model ]
> 
> - Can we refactor ap_getline() without pushback and how?

I'm looking forward to these answers and solutions too.  If pushback isn't
a requirement, then it waits (2.1 ? 3.0 ?) until there is a demonstrated
requirement.

> > I think the point is, we are all tired and want to see folks _use_
> > Apache 2.0.  After that, some of these issues will come back into
> > better focus for 2.1 ;)
> > 
> > Any objections if we begin a ROADMAP file for good 2.1/2.2/3.0 
> > generation ideas?
> 
> ++1.  -- justin

Consider it done, if not tonight, sometime tommorow [the ROADMAP idea wasn't 
mine, exactly, but I'll wait to credit the originator until I discover if 
they wish to be identified :]

Bill