- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sun, 12 Oct 2008 19:59:32 +0200
- To: Brian Smith <brian@briansmith.org>
- CC: 'Henrik Nordstrom' <henrik@henriknordstrom.net>, "'A. Rothman'" <amichai2@amichais.bounceme.net>, ietf-http-wg@w3.org
Brian Smith wrote: >> Brian, do you disagree with the proposed resolution for issue 133, or >> did you miss it? > > * Clients should accept single-part multipart/byterange responses, but > servers shouldn't generate them since RFC 2616 says that every > multipart/byterange request has at least two parts. > > * Clients should not send range requests that can be trivially combined > (e.g. 0-2, 3-5), but they should accept any combination that the server > does. Server implementers shouldn't waste time trying to combine ranges; if > a client split contiguous ranges into separate ranges, it probably had a > reason for doing so. > > * Clients should send ranges in the order they want the ranges to be > returned; servers shouldn't reorder out-of-order ranges (3-5, 0-2), even if > they are contiguous. Reordering and combining these ranges defeats the > purpose of splitting the request into ranges in the first place (e.g. Adobe > Reader's behavior). > > * Clients shouldn't send obviously overlapping ranges (ranges that overlap > for any reason other than the combination of a regular range and a suffix > range). > > * The server is free to reject any request (overlapping range requests or > otherwise) where the request would exhaust too many server resources. I think I agree with all these statements. What I still want to know is: do we need to make any additional changes to the spec? Is this all just "common sense", or should something of this become a normative requirement? If not, should it be added as guidance? BR, Julian
Received on Sunday, 12 October 2008 18:00:26 UTC