httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
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" <rbb@covalent.net>
> Sent: Sunday, October 07, 2001 8:03 PM
>
> > On Sunday 07 October 2001 05:54 pm, William A. Rowe, Jr. wrote:
> > > From: "Greg Stein" <gstein@lyra.org>
> > > 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 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
filter.

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

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
______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Mime
View raw message