httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: byterange filter + apr_brigade_partition
Date Fri, 08 Jun 2001 18:45:16 GMT
On Fri, Jun 08, 2001 at 12:48:40PM -0400, Cliff Woolley wrote:
>...
> range-end where necessary.  So in theory, these particular calls to
> apr_brigade_partition() should never fail, unless something really
> 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? :-)

> 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'm tempted to just keep on ignoring the [slim] possibility of an error in
> this case and to simply add a comment explaining these assumptions.
> Maybe an AP_DEBUG_ASSERT() on the return values to add future-proofness?

Definitely not an AP_DEBUG_ASSERT. Then we would never see anything out in
the real world. It will just mysteriously die.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message