On 09/06/2008 01:30 PM, Eric Covener wrote:
On Sat, Sep 6, 2008 at 4:38 AM, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
@@ -673,7 +690,7 @@
}
b = APR_BRIGADE_FIRST(bb);
if (b == APR_BRIGADE_SENTINEL(bb) ||
- APR_BUCKET_IS_EOS(b)) {
+ APR_BUCKET_IS_METADATA(b)) {
break;
}
rv = apr_bucket_read(b, &bucket, &bytes_in_bucket,
APR_BLOCK_READ);
Don't we need to handle flush buckets separately and flush our buffer
downstream as far as we can in this case?
I think this part is correct in the patch. This path is used on input
only, and the break-on-metadata will causes us to:
move remaining input into our filter state
create a heap bucket containing all the bytes we've xlated so far
(collected in a char*)
add the heap bucket onto the (emptied) bb being returned
add any metadata at the head of the input/filterstate to the bb being returned
The only thing held onto past the flush would be leftover bytes from
(apr_xlate() == APR_INCOMPLETE), for which it seems better to send
what we had (i.e. multibyte sequence with a flush bucket separating
the bytes doesn't get flushed)
You are corerect. Thanks for explaining. I missed that this only happens
in the input filter. Apart from the fact that the current code flow does
it correct as you have explained, flush buckets do not seem to make a lot of
sense in an input brigade anyway.
Regards
Rüdiger
