- From: Henrik Nordstrom <henrik@henriknordstrom.net>
- Date: Wed, 10 Dec 2008 22:37:13 +0100
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Thu, 2008-12-11 at 00:10 +1100, Mark Nottingham wrote: > Even if your interpretation is the latter one, a much simpler > formulation is that it can't be used for message delimitation with > HTTP/1.0 receivers (next hop). No, it MST NOT be used for message delimitation to ANY recipient including HTTP/1.1 clients unless they indicate they support the media type (where the only method doing so in 2616 is multirange requests). And MUST NOT be used as delimiter if there is reason to suspect you are talking to a HTTP/1.0 proxy. Additionally the media type as such SHOULD NOT be used in contexts where it does not make sense, but that's a pretty minor and obvious to anyone I'd say. The text in 4.4 ยง4 is mainly about delimiting. The fact that it also by sideeffect restricts when multipart/byteranges may at all be sent is coincidental and not the main purpose of that text. It can not be moved out from 4.4 without loosing context, but I am quite fine with having 4.4 narrowed down to only limit when multipart/byteranges is valid as delimiter. It's already covered sufficiently at other places how it should be used as media type in it's normal intended use (see Content-Range), and there is not really any reason why 4.4 should limit other applications of the media type as such, only it's property as delimiter. Proposed updated text: 4.If the message uses the media type "multipart/byteranges", and the transfer-length is not otherwise specified, then this self- delimiting media type defines the transfer-length. This media type MUST NOT be used as delimiter unless the sender knows that the next hop recipient can parse it; the presence in a request of a Range header with multiple byte-range specifiers from a 1.1 client implies that the client can parse multipart/byteranges responses. A range header might be forwarded by a 1.0 proxy that does not understand multipart/byteranges; in this case the server MUST delimit the message using methods defined in items 1,3 or 5 of this section. Note: I am not entirely happy with the language in "the presence in a request of a Range ..." but that may just be my limited english.. kept the original text as much as possible and that text do say the right thing. Regards Henrik
Received on Wednesday, 10 December 2008 22:37:47 UTC