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?
Thoughts?
--Cliff
--------------------------------------------------------------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
