httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <stefan.eiss...@greenbytes.de>
Subject Re: svn commit: r1707087 - /httpd/httpd/trunk/modules/debugging/mod_bucketeer.c
Date Wed, 26 Apr 2017 09:26:11 GMT

> Am 26.04.2017 um 11:14 schrieb Plüm, Rüdiger, Vodafone Group <ruediger.pluem@vodafone.com>:
> 
> 
> 
>> -----Ursprüngliche Nachricht-----
>> Von: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
>> Gesendet: Mittwoch, 26. April 2017 10:55
>> An: dev@httpd.apache.org
>> Betreff: Re: svn commit: r1707087 -
>> /httpd/httpd/trunk/modules/debugging/mod_bucketeer.c
>> 
>> Eh, not really into mod_bucketeer and its use cases, but some
>> observations after a quick scan:
>> 
>> line 99:
>>            rv = ap_pass_brigade(f->next, ctx->bb);
>>            apr_brigade_cleanup(ctx->bb);
>> 
>> line 146:
>>                        rv = ap_pass_brigade(f->next, ctx->bb);
>>                        if (rv) {
>>                            return rv;
>>                        }
>>                        apr_brigade_cleanup(ctx->bb);
>> 
>> such things only work if an EOS always comes *before* an EOR bucket
>> (case 1)
>> or of no DATA bucket of any kind follows an EOR.
> 
> Correct, but with the BUCKETEER filter being a resource filter that should
> not happen.

Because the implementations of everything else in the server do not do it? Should we then
add a filter that checks exactly that? 

I am not saying this mockingly, but am serious. If we have such contracts implicit somewhere
(and afaik not documented), would it not be better to make that explicit? The performance
cost of a filter inspecting bucket orderings should be negligible, or?

-Stefan
Mime
View raw message