httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject bug in ap_get_client_block (wrong handling of EOS)
Date Tue, 13 May 2003 09:00:32 GMT
ap_get_client_block API docs says:

  * @return Number of bytes inserted into the buffer.  When done reading, 0
  *         if EOF, or -1 if there was an error

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.

Possible solutions:

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)

1a) same as (1) but adjust apr_brigade_flatten to recognize situations when it 
read the EOS bucket, and somehow pass that knowledge back to the caller. 
Probably a bad idea since it adds a performance hit for situations where this 
check is not needed.

The current behavior is broken and ap_get_client_block shouldn't be used at 
all, so it doesn't really matter if we change the API. So unless we can 
maintain the status elsewhere, need to modify the API for get_client_block to 
always return status, but have the size returned by reference.


There is this comment in the code (not header docs):

     /* We lose the failure code here.  This is why ap_get_client_block should
      * not be used.
      */
So if it shouldn't be used, remove it compeletely? deprecate? fix?

While we are at this issue, I've a related question about well behaved 
filters, since my filters were failing to handle faulty ap_get_client_block 
calls, after EOS has been missed:

Should all filters remember in their context that they have seen/sent eos?

If so, what good filters should do if they are being called again, even though 
they have sent the EOS bucket already?

__________________________________________________________________
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