httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: [PATCH] mod_ssl input filtering...
Date Mon, 08 Oct 2001 02:03:15 GMT
From: "Ryan Bloom" <>
Sent: Sunday, October 07, 2001 8:03 PM

> On Sunday 07 October 2001 05:54 pm, William A. Rowe, Jr. wrote:
> > From: "Greg Stein" <>
> > Sent: Sunday, October 07, 2001 7:35 PM
> >
> > > Even more? OtherBill's latest "compromise" looks exactly like what we
> > > were *already* doing.
> >
> > I was frustrated that the vast majority of content filters had to
> > now handle a TON of state information and 'carry' their callers, which
> > I thought was wrong.  Based on this news that only connection filters
> > handle the readbytes argument (and all the rest pass it on) I can live
> > with this.
> Huh?  What does that mean that only connection filters handle the readbytes
> argument?  That is completely bogus.  If we are designing a system where we
> pass an argument to every filter, but not every filter needs to respect it, then
> we are doing this wrong.  If that is the goal, then put the readbytes information
> into the conn_rec where it belongs, so that it is only visible to connection
> filters.  Every single input filter must respect the readbytes argument that it is
> passed.

That makes as much sense as arguing that a handler should respect CONTENT_LENGTH :)

It doesn't make sense.  The only filters that need to worry about readbytes are 
those ones that pull data off the wire, and those that decode the protocol-specific

In other words - readbytes is a protocol argument, not a general-purpose packet
constraint.  It's used only where we know how much data we are handling.

Once data passes through a content filter, any preconceptions of 'how much' data
is there becomes imaginary.  Noone knows how much can be read, because content
filters in the chain can grow and shrink the data (charset/formatting translations)
and you don't know till you've read it all, how much exactly you've got.

Now that is MY argument, it doesn't appear to be Greg's opinion.  In fact, my
comprimize appears asymertrical to Greg's theory of input filtering.


View raw message