On 9/26/2011 12:07 PM, Jim Jagielski wrote: > > On Sep 26, 2011, at 12:58 PM, Stefan Fritsch wrote: > >> >> But we are breaking quite a few popular clients here: VLC, everything >> based on lavf, firefox (the ogg media support). >> >> And httpd violates a SHOULD with the current form of RFC 2616 14.35.1: >> >> If a syntactically valid byte-range-set includes at least one byte- >> range-spec whose first-byte-pos is less than the current length of >> the entity-body, or at least one suffix-byte-range-spec with a non- >> zero suffix-length, then the byte-range-set is satisfiable. >> Otherwise, the byte-range-set is unsatisfiable. >> >> This means "0-" is satisfiable. >> >> If the byte-range-set >> is unsatisfiable, the server SHOULD return a response with a status >> of 416 (Requested range not satisfiable). Otherwise, the server >> SHOULD return a response with a status of 206 (Partial Content) >> containing the satisfiable ranges of the entity-body. >> >> In this case, I am strongly in favor of fixing the RFC first and >> changing httpd's behaviour only after that. >> > > Certainly we can have a config option on whether to > be strict or loose about it… > > ie: > > strict: 0- returns 200 > loose: 0- returns 206 > > and we can have 2.0 and 2.2's default be loose and 2.4's > be strict.
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.
