On 24 Aug 2011, at 16:35, Tim Bannister wrote: > On Tue, Aug 23, 2011, Roy T. Fielding wrote: >> And the spec says ... >> >> When a client requests multiple ranges in one request, the >> server SHOULD return them in the order that they appeared in the >> request. >> >> My suggestion is to reject any request with overlapping ranges or more >> than five ranges with a 416, and to send 200 for any request with 4-5 >> ranges. There is simply no need to support random access in HTTP. > > Deshpande & Zeng in http://dx.doi.org/10.1145/500141.500197 describe a > method for "streaming" JPEG 2000 documents over HTTP, using many more than > 5 ranges in a single request. > A client that knows about any server-side limit could make multiple > requests each with a small number of ranges, but discovering that limit > will add latency and take more code.
Agreed - I've seen many 10's of ranges in a single request for things like clever PDF pagination (or tiny TIFF quicklooks for the pages), clever http fake streaming and clever use of jumping to i-Frames. I think we just need to sit this out - and accept up to RequestFieldSize limit bytes on that line - and then do a sort & merge overlaps as needed. And then it is fine. Dw
