On 8/24/2011 3:56 PM, Roy T. Fielding wrote: > On Aug 24, 2011, at 8:35 AM, 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. > > I have no interest in supporting such a use case over HTTP. > Consider how stupid it is to request ranges like their example > > Range: bytes=120-168,175-200,205-300,345-346,400-500,555-666, > 667-800,900-1000,2500-2567,2890-3056,5678-9000, > 10000-12004,12050-12060,15600-15605,17000-17001, > 17005-17010,17050-17060,17800-17905,20000-20005 > > keeping in mind that between each one of those ranges will be > a multipart boundary of approximately 80 bytes! Hence, any > range request that contains gaps of less than 80 bytes should > be considered a denial of service, or at least an idiot programmer > that deserves to be slapped by Apache. > > To be clear, I am more than willing to rewrite the part on > Ranges such that the above is explicitly forbidden in HTTP. > I am not sure what the WG would agree to, but I am quite certain > that part of the reason we have an Apache server is to protect > the Internet from idiotic ideas like the above.
Then if we are opening up the spec for sensible revision, particularly in the gray areas of what was not answered, insisting that the server is free to respond to the client with any serialized superset of their requested ranges [deliberately ignoring the SHOULD in the section you had previously quoted] is the right answer. In your pedantic case above, adjacent ranges < 80 bytes apart would be processed as a single merged range. A client insisting on ranges must be prepared to follow the rules provided to all proxies in that section on range handling, given that the proxy case is already one user agent case, and the requirements for proxy handling should certainly be applied in the generic case. The spec does not actually state that ranges are returned 1:1 in sequence, and I believe we should liberally read this to protect the server from abuse. Perhaps we have a threshold number of ranges which trigger the behavior, or any overlapping (apparently abusive) range requests would trigger the behavior regardless.
