httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: apache-2.0/src/main http_protocol.c
Date Thu, 12 Oct 2000 23:18:25 GMT
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/

Mime
View raw message