httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <>
Subject Re: byterange filter + apr_brigade_partition
Date Fri, 08 Jun 2001 19:10:07 GMT
On Fri, 8 Jun 2001, Greg Stein wrote:

> > catastrophic happens between the calls to apr_brigade_length() and
> > apr_brigade_partition().  That's why it worked fine before to just ignore
> > the possibility of a NULL return from apr_brigade_partition()... it just
> > shouldn't ever happen.
> It can definitely happen.
> Consider a brigade that contains a PIPE bucket from a CGI. When we go to
> partition it, we read from the PIPE. Are you *sure* that read will never
> return an error on us? :-)

But there won't be a PIPE bucket in the input brigade by the time it gets
to the apr_brigade_partition() calls, because apr_brigade_length() will
have already seen and read from any such buckets, morphing them to HEAP
buckets.  All apr_brigade_partition() will ever see is the "plain"
buckets, ie ones that you don't need to read from to operate on.  If the
read on the (former) PIPE/SOCKET buckets was going to fail, it would have
failed earlier in the call to apr_brigade_length().  Right?

> > If we do want to explicitly handle errors here, I think the way to do it
> > is to move the calls to apr_brigade_partition() above the block that adds
> > the range specifiers to the output stream and simply "continue;" if one
> > of the calls fails for some wacky reason.
> Sure. We should also log an error because it means that something has broke
> down during a bucket read. A failing CGI, for example.

I'll buy this... if you can convince me that these calls to
apr_brigade_partition() will ever have a reason to read from any bucket.
=-)  Still, I guess it couldn't hurt to have a "something really, really
bad happened" message get logged...


   Cliff Woolley
   Charlottesville, VA

View raw message