httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: [PATCH] mod_ssl input filtering...
Date Mon, 08 Oct 2001 15:12:47 GMT
On Sunday 07 October 2001 07:03 pm, William A. Rowe, Jr. wrote:
> 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
> 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 content.
> 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.

No Will, the three previous paragraphs all all incorrect, but I do believe that
they show where the confusion is. The content-length during output filtering
is not comparable to readbytes in input filtering, it is comparable to content-
length in input filtering.  Just as the only filter that handles C-L for output filters
is the C-L-filiter, the only filter that handles C-L for input filters, is the HTTP_IN

Readbytes has nothing at all to do with the protocol, it is a construct that is
required for filtering. If we didn't have filters, we wouldn't have readbytes, but
we have always had content_length on input, it is stored in remaining in the

The readbytes argument is specifically telling the lower level filter exactly how
much data the current filter can handle at one time.  That is it.

Ryan Bloom
Covalent Technologies

View raw message