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 16:48:40 GMT
On Fri, 8 Jun 2001, Cliff Woolley wrote:

> There are special protocol rules for byteranges, though...  You're
> supposed to satisfy as many of the requested ranges as you can, IIRC...
> only if NONE of them are satisfiable is it really an error.  I think.  Is
> that right?  I guess I have to go read the damned RFC.  =-)

According to the RFC, you just ignore byteranges you can't satisfy [as
long as there's at least one that you can].  But a range-end past the end
of the entity does not imply non-satisfiability... you just adjust the end
to be length-1.

What I didn't realize is that all of this is already handled by the filter
beforehand, because it calls apr_brigade_length() to find out the absolute
length and parse_byteranges() handles the adjustments to range-start and
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.

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.

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?



   Cliff Woolley
   Charlottesville, VA

View raw message