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 07:25:11 GMT
Justin Erenkrantz wrote:
> --On Wednesday, May 14, 2003 3:08 PM +1000 Stas Bekman <stas@stason.org> 
> wrote:
> 
>>> 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.
> 
> 
> The public API documentation doesn't have lots of things.  ;-)

Sure, what do we deliver the source for ;)

>> a similar patch attached to reply to Jeff's post. Your other proposal 
>> sounds
>> good too (faster).
> 
> 
> The issue is that r->remaining isn't used anywhere, but it's set by 
> ap_setup_client_block.  So, I think we can use it for this purpose. 
> r->remaining==0 used to mean EOS a long time ago (and was how 
> ap_get_client_block knew when it was EOS and always returned 0 if that 
> was 0).

I'd rather have a special flag. But if others feel better about using
r->remaining and it is not clobbered elsewhere that's fine with me.

>> That's cool with me. Mark those old broken functions as deprecated.
> 
> 
> I think we should just remove them in 2.1.  Mark the ap_*_client_block 
> API as deprecated (but supported) in 2.0 and outright toss 'em in 2.1.

+1

>>> 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.
> 
> 
> Right, but the point was that output_filters have that semantic of not 
> sending EOS twice because of the r->eos_sent safeguard.  However, the 
> r->eos_sent is a big giant kluge as well.  It's needed for HTTP 
> pipelining.  It'd be nice to remove that if possible.

Last time I've looked at the implementation (about half a year ago), there 
were several cases when core filters would send two EOS buckets, since the 
safeguard is not always used. I've reported this, but I think it's still there.

>> 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.
> 
> 
> The stacktrace is a good way to find out what f->prev was.  =)  -- justin

You mean using assert? So far I hate all uses of assert in httpd, because it 
always triggers a segfault in kill ;)

__________________________________________________________________
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