httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <rpl...@apache.org>
Subject Re: svn commit: r692567 - /httpd/httpd/trunk/modules/filters/mod_charset_lite.c
Date Sat, 06 Sep 2008 13:55:20 GMT


On 09/06/2008 01:30 PM, Eric Covener wrote:
> On Sat, Sep 6, 2008 at 4:38 AM, Ruediger Pluem <rpluem@apache.org> 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





Mime
View raw message