- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 05 Aug 2008 20:06:41 +0200
- To: Yves Lafon <ylafon@w3.org>
- CC: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Yves Lafon wrote: >> Playing the devil's advocate: is there *any* range unit other than >> "bytes" we can think of that is indeed independent of formats? Right >> now, I can't think of any. > > The text proposed by Mark uses SHOULD NOT, not MUST NOT. In some case, > it might be ok to use a format specific range unit, like 'character' > (for text content in multi/variable-bytes encodings), or 'frames' for > video content. I am not saying that those are good examples, just that > it may happen. I totally agree this could happen. My point was that in practice most extensions may be format specific, thus even a SHOULD NOT would be to strong. > ... >>> Furthermore, Section 6.2 - the BNF says: >>> >>>> Content-Range = "Content-Range" ":" content-range-spec >>>> >>>> content-range-spec = byte-content-range-spec >>>> byte-content-range-spec = bytes-unit SP >>>> byte-range-resp-spec "/" >>>> ( instance-length | "*" ) >>>> >>>> byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) >>>> | "*" >>>> instance-length = 1*DIGIT >>> >>> This does not allow other range units to be used. If we keep them, >>> this BNF needs to be changed to something like: > > Well, is it forbidden to ask servers to give back byte-ranges that a cache > can... cache ? What is transported is bytes, so requesting the 10 first > characters of an utf-8 document and receiving 12 bytes using a > Content-Range in bytes might help caches to DTRT, so I am not sure that > the proposed BNF change is desirable (as "exotic" Content-Ranges won't > be cached for sure). > ... It would be useful for caches, but not for the client, right? It would still need to know what range with respect to the original range unit was returned. I also note that Range (Section 6.4) would need additional work as well. BR, Julian
Received on Tuesday, 5 August 2008 18:07:26 UTC