httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: bug in ap_get_client_block (wrong handling of EOS)
Date Wed, 14 May 2003 05:08:53 GMT
Justin Erenkrantz wrote:
> --On Tuesday, May 13, 2003 7:00 PM +1000 Stas Bekman <stas@stason.org> 
> wrote:
> 
>> but this is bogus. If the EOS bucket arrives in the same bucket 
>> brigade with
>> real data, ap_get_client_block() will return the size of the read data,
>> completely missing the fact that EOS went through. Next it'll be called
>> again (because the caller wasn't signalled with EOF) and bad things 
>> happen
>> because there are no rules for how filters should behave after they have
>> processed EOS the last time they were called.
> 
> 
> The ap_get_client_block() API can't support that semantic of a 
> partial-read given its interface.  ap_get_client_block is a kluge that 
> only exists to make people who want partial source compatibility with 
> 1.3 modules.  ap_get_brigade should be used instead...

The public API documentation doesn't say anything about this.

>> 1) replace apr_brigade_flatten with a loop that reads the data and 
>> sets the
>> eos flag, so the next time this function is invoked it'll immediately 
>> return
>> EOF. (not sure where to store this flag though)
> 
> 
> No, that's lame.

a similar patch attached to reply to Jeff's post. Your other proposal sounds 
good too (faster).

[...]

> I'm sick of dealing with the conflicts of keeping the old input API with 
> the new input API.  They aren't equivalent and the mapping is just 
> painful and kills performance when people could easily use the brigade 
> model instead.

That's cool with me. Mark those old broken functions as deprecated.

>> Should all filters remember in their context that they have seen/sent 
>> eos?
> 
> 
> No.  There is a global r->eos_sent though.

but it's not the same as r->seen_eos, and it's used for output filters.

>> If so, what good filters should do if they are being called again, even
>> though they have sent the EOS bucket already?
> 
> 
> Blow up and point fingers at the culprit who called EOS twice.  =)

The problem is that users will come complaining to the author of a good 
module, which may fail and not to the author of the faulty module. Hence it'd 
be nice to have a methodology for protecting ourselves from faulty situations.

I suppose I can set a flag in my filters that identifies whether eos has been 
sent already, and if they get called again, simply die pointing the finger to 
the faulty filter. The problem: there is no f->prev, but only f->next, so 
there is no (easy) way to communicate this information.

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Mime
View raw message