Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 24223 invoked by uid 500); 8 Oct 2001 15:25:58 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 24180 invoked from network); 8 Oct 2001 15:25:57 -0000 Message-ID: <014301c1500d$954664e0$93c0b0d0@roweclan.net> From: "William A. Rowe, Jr." To: , References: <20011008010339.7A50746DFC@koj.rkbloom.net> <018901c14f9d$e90a2320$93c0b0d0@roweclan.net> <20011008151247.C3FF546DFC@koj.rkbloom.net> Subject: Re: [PATCH] mod_ssl input filtering... Date: Mon, 8 Oct 2001 10:25:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 08 Oct 2001 15:26:21.0290 (UTC) FILETIME=[954F8CA0:01C1500D] X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N From: "Ryan Bloom" 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