This is the same issue I was dealing with in mod_proxy
that I submitted the patch for in 'BUG 19954 [PATCH] HTTP
tunneling through reverse proxy does not always work'. In my case
I didn't care what the read size was, but I needed to forward
on whatever had been read, even if it was less than
On Wed, 9 Jul 2003, Juan Rivera wrote:
That way a filter could ask for more or less bytes than the 8K.
That's what apr_brigade_partition() is for. Does that not get you what
you want? And anyway, having a runtime-configurable buffer size would
make the bucket allocator WAY more complicated
Juan Rivera [EMAIL PROTECTED] writes:
[...]
That way a filter could ask for more or less bytes than the 8K.
A filter can ask now- it just won't get more than 8K
per ap_get_brigade call.
FWIW, I think the best approach would be to put a loop
in httpd-2.0/server/core.c's core_input_filter(),
Title: RE: APR_BUCKET_BUFF_SIZE question
I figured it has to do something with the way pools work. Would it make a difference if the buffer size used is always a multiple of APR_BUCKET_BUFF_SIZE? Like 16, 32, 64?
Do you know where the 8K number come from? Is it an empirical number
On Wed, 9 Jul 2003, Juan Rivera wrote:
I figured it has to do something with the way pools work.
Nope, buckets don't allocate anything from pools.
Would it make a difference if the buffer size used is always a multiple
of APR_BUCKET_BUFF_SIZE? Like 16, 32, 64?
Lots of the code assumes that
