httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: cvs commit: apache-2.0/src/main http_protocol.c
Date Thu, 12 Oct 2000 19:54:45 GMT

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

The problem with this, is that it is a logistical nightmare at the Apache
level.  If ap_get_client_block passes down 10, and the filter returns 10,
does that mean that there were 10 bytes read from the network or 5 bytes
read, and then a 2 for 1 conversion was made?

It is impossible to tell.  This means that filters need to add an EOS
bucket when they have read the correct amount of data.  But even that
won't work, because the conversion may not be standard.

Take the uncompress filter.  If I read 5 bytes from the network, I could
get 6,7,8,9... bytes out after the uncompress.  So, if ap_get_client_block
sends down 10, and the filter returns 8, are there 2 bytes left or more?

There is a disconnect here, because the lowest level needs to know how
much to read, but the upper level needs to know not only how much was
read, but also how much was returned.

This leads me to the next iteration of the API, which is getting more and
more complex.  :-(

inputfilter_func(filter_t*, bucket_brigade*, apr_ssize_t len_to_read,
apr_ssize_t *len_read, apr_ssize_t *len_returned)

The len_to_read and len_read could actually be combined with a slight
re-org.  :-)


So, this leaves us with:

inputfilter_func(filter_t*, bucket_brigade*, apr_ssize_t *len_remaining,
apr_ssize_t *len_returned);

The first two are obvious.  The third is the amount of data still to be
read from the network.  The initial call still has the -1, 0, +int
characteristics.  Same meaning behind them too.  On return though, it is

-1 or 0 if those were passed in, or

initial_value - length_actually_read if +int was passed in.

This allows a higher level filter to keep track of where we are.

The len_returned is because we most likely aren't dealing with char
strings, so we need to know how much actual data was returned to the
higher filters.  ap_get_client_block uses this data to deal with the
returned data.

What does this all imply?  Only the topmost filter (consumer) and the
filter that reads from the brigade are allowed to modify the len_remaining

This is much uglier than I had hoped for, but I am 100% convinced that
a pass-back brigade won't work.  I have explained why enough times that I
would prefer to not do it again unless somebody asks me to.

Please comment on this design.  If we all agree to it, I'll implement
later today.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message