Check out
http://svn.apache.org/viewvc?rev=1175980&view=rev
Note that '0-1023,1024-' merges to 0- and and single
range and should also now return a 206 (due to the change from
>= to > in the sum_lengths check)…
On Sep 26, 2011, at 2:01 PM, William A. Rowe Jr. wrote:
> The RFC won't be updated that quickly. And I doubt this is the sort
> of thing to put in a directive. We've really become lax about making
> any sort of substantial protocol decisions on behalf of the user, turning
> too many into 'well, it could be this way, or maybe that, good luck'.
>
> Here's the underlying reason to revert...
>
> If we are arguing for bandwidth efficiency, and the client must probe
> the server due to too many erronious accept-ranges: bytes responses,
> then probing with bytes '0-1' or even '0-1023', followed by another req
> for '1024-' for the remainder of the response is more bandwidth intensive
> than giving them the original results for a '0-' query.
>
> And if '0-1023,1024-' is not merged into a 200, it at least devolves
> into a multipart response consuming more response bandwidth than if
> we had satisfied the original '0-' with a single-part range response.
>
> I'm giving this a bunch of thought, and unless someone can demonstrate
> a less bandwidth-intensive way of probing that ranges are truly supported,
> then my -0 is rapidly shifting to a +1 for this requested fix.
>
