Re: NEW ISSUE: status of multipart/byteranges

On mån, 2007-11-19 at 03:02 +0000, Jamie Lokier wrote:

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

Yes.

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

You can't safely deduce things this way. It's a MUST NOT which only says
that you are forbidden unless, not that it's otherwise ok. You also have
to combine this requirement with all other requirements around the use
of this media type. But yes, in theory..

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

Yes, obviously.

> Either parse it as multipart/byteranges, or reject it as malformed.

Yes..

Which makes me wonder how Squid behaves if seeing a multipart/byteranges
in request. Something I need to test. Quite likely it will fail just as
badly as Apache, not expecting this message format in requests.

Regards
Henrik