Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Thu, 12 Oct 2000 16:18:25 -0700
From: Greg Stein <gstein@lyra.org>
To: new-httpd@apache.org
Subject: Re: cvs commit: apache-2.0/src/main http_protocol.c
Message-ID: <20001012161825.M347@lyra.org>
Mail-Followup-To: new-httpd@apache.org
References: <39E5F7CC.FB3C2AC1@raleigh.ibm.com>
 <Pine.LNX.4.21.0010121140430.30118-100000@koj>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <Pine.LNX.4.21.0010121140430.30118-100000@koj>;
 from rbb@covalent.net on Thu, Oct 12, 2000 at 12:21:02PM -0700

On Thu, Oct 12, 2000 at 12:21:02PM -0700, rbb@covalent.net wrote:
>...
> > I think this is OK for now, but the global argument passing thing is
> > pretty shaky.  Sure, I love the concept of parameters.  But since we
> > don't have a clean way today to target a specific filter with a specific
> > dynamic parameter, the "one length argument applies to all filters"
> > approach means that we can't implement any input filters that increase
> > the length of the content.  gunzip, multi-byte charset xlation, ... 
> > Once one filter increases the length of the data, what should the next
> > filter upstream do with the length argument?  How would you implement
> > those input filters in a general fashion?
> 
> The solution is to use an integer pointer instead of an integer in the
> filter function argument list.  Basically, on input we are specifying the
> maximum amount that we will allow to be READ, not returned, but read.  If
> the filter changes the data, then the length has to grow, and the filter
> has to inform the caller of this.
> 
> This is not how the code is written currently, but it is a simple change
> if people agree.

Um. I disagree.

1) I don't understand your explanation about read vs return.
2) When the filter is called, the caller is *only* interested in what comes
   back to it. Whatever the filter does underneath, that is the filter's
   problem.
   [ if http_filter read past the end of the request, then it better pretend
     that it didn't, and save the data for the next request for later ]

I'm not sure what Jeff means about "can't have filters that increase the
length." Sure we can. Consider a gunzip filter. Somebody calls into the
filter saying "give me 1024 bytes of data". gunzip calls to the next one and
says "give me however much you want, I can take it all." It then unzips
whatever is returned. It returns (up to) 1024 bytes and saves any remainder
off to the side, for a later call into the gunzip filter. Only when that
saved-to-the-side bit runs out, does it call down for more.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/