httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject Re: [PATCH] mod_ssl input filtering...
Date Mon, 08 Oct 2001 15:25:57 GMT
From: "Ryan Bloom" <rbb@covalent.net>
Sent: Monday, October 08, 2001 10:12 AM


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

Ok, here we all agree.  Input C-L is _only_ meaningful to HTTP_IN, and Output C-L can
only be constructed at or immediately before HTTP_OUT, after any filtered expansion 
and reduction occurs.

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

Ok... here's where my point was missed.  _Because_ it understands C-L, HTTP_IN knows
how many bytes to read, therefore readbytes means something when HTTP_IN makes
its readbytes-limited request.  [Likewise, it understands chunking, so again HTTP_IN
will readbytes-limit its request to a chunk at a time after it reads the chunk header
line.]

SSL has a similar construct to get the remaining bytes of the current packet to decode.

Remember that nobody can trust input C-L, except for the HTTP_IN filter.

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

It is not saying how much it wants to handle, it is telling the lower level filter
how many bytes are pertinent.  And once you hit Content/Body filters, there is no
real number for how many bytes are pertinent until the filters have all finished
transforming that body.  Even if a body filter used some byte prefix, the bytes 
following could have been munged by another filter between this filter and HTTP_IN, 
such as charset translation [such a filter should become a protocol filter, of course.]

This discussion is over, though.  I'm convinced the resulting input filters will be
bloated and unmanageable.  But, since Greg agrees that -1 is appropriate, we can
implement that solution again for SSL, get that filter working, and go on with our
lives.  I have nothing more to contribute to the 'eliminating duplicate code' debate.
If anyone else sees value in this argument, feel free to restate it, I've obviously
done an insufficient job at describing my intended behavior and it's rational.

Bill



Mime
View raw message