On 8/24/2011 10:55 AM, "Plüm, Rüdiger, VF-Group" wrote: > > Hm. If I got it right what Roy says above about the spec sorting and merging > is > not an option as we need to stick to the order and number of ranges the client > requested.
No. Merging -is- recommended. 10.4.17 416 Requested Range Not Satisfiable A server SHOULD return a response with this status code if a request included a Range request-header field (section 14.35), and none of the range-specifier values in this field overlap the current extent of the selected resource, and the request did not include an If-Range request-header field. (For byte-ranges, this means that the first- byte-pos of all of the byte-range-spec values were greater than the current length of the selected resource.) Note; the FIRST byte-pos is invalid. It doesn't suggest that 416 can be used for semantically valid ranges longer than the document length, or to represent that valid byte ranges overlapped. In fact, if ONE range can be satisfied, 416 is not appropriate. So if ONE range can be satisfied, it is to be returned (this is reiterated in 14.16), which may obviously be out-of-sequence. I would suggest we simply ignore/extend for all overlapping ranges rather than rejecting them. E.g. 0-, 40-50 becomes 0- 0-499, 400-599 becomes 0-599 1000-1075, 200-250, 1051-1100 becomes 1000-1100, 200-250 -Sorting- is to be avoided, although as its a SHOULD, I am happy to break that recommendation if there is no reasonably efficient solution to the server side. As Roy suggests, random access on the server side is very dubious. A client issuing rich requests should assemble them and must respect the individual Content-Range response headers.
