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.
....Roy
