httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: Remove input filtering as a showstopper?
Date Tue, 20 Nov 2001 04:19:32 GMT
On Mon, Nov 19, 2001 at 09:57:50PM -0600, William A. Rowe, Jr. wrote:
> If you mixed up ap_getline into the input filtering semantics,
> you were very confused, please split those issues again.

Yeah, your update to the STATUS file seems like the right
division here.  Apologize for the confusion, but the wording
wasn't mine.  =)  The ordering is still up in the air, but
the behavior may or may not be.

> 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.

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.

[ Non-pushback model ]

- Can we refactor ap_getline() without pushback and how?

> 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

View raw message