- From: Jamie Lokier <jamie@shareable.org>
- Date: Mon, 19 Nov 2007 03:02:53 +0000
- To: Henrik Nordstrom <henrik@henriknordstrom.net>
- Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, ietf-http-wg@w3.org
Henrik Nordstrom wrote:
> > ... this particular case, even though the specification suggest the
> > opposite, I read it to say, all implementations have to support that
> > and support it in all messages, like requests and non-206 responses.
> > Apache 2.2.6 for example treats
>
> Not quite. See 4.4 Message Length. There is a MUST level requirement
> governing when this self-delimiting media type may be used.
This media type MUST NOT be used unless the sender knows that the
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.
This suggests that there might be other situations where the sender
knows that the recipient can parse it, which aren't defined by HTTP.
Such as specific out of band knowledge of the recipient, or prior
negotiation.
It also suggests that even as defined by HTTP, the use of a Range
header with multiple byte-range specifiers from a 1.1 client permits
multipart/byteranges responses in any response to that client, not
just 206, and not just the response corresponding to that specific
request.
But however you look at it, and whether the message is allowed or not,
it is _always_ incorrect to parse a HTTP/1.1 message with media type
"multipart/byteranges" and no Content-Length and no chunked encoding
as though it has an empty body, followed by a new message.
Either parse it as multipart/byteranges, or reject it as malformed.
-- Jamie
Received on Monday, 19 November 2007 03:03:01 UTC