Re: NEW ISSUE: status of multipart/byteranges

* Henrik Nordstrom wrote:
>On sön, 2007-11-18 at 14:51 +0100, Bjoern Hoehrmann 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.
>Not quite. See 4.4 Message Length. There is a MUST level requirement
>governing when this self-delimiting media type may be used.

I can write some client code that can parse such messages, but I would
pass the request through some HTTP library which may then well consult
a proxy and so on, and it's quite likely that somewhere on the line we
have an implementation that does not determine the message length from
the self-delimiters or does so incorrectly and perhaps even forwards a
possibly problematic response.

CPAN for example has modules that help to parse such messages, and the
HTTP client modules allow you to set a Range header with multiple
values, but they are usually not prepared to cope with the self-
delimiting nature of this type. The XMLHttpRequest draft also suggests
to allow scripts to set the Range header, but says nothing about the
implementation having to support the type, and the very text you refer
to suggests that it's okay for clients to have no support for it.

Detecting the end of a message correctly is rather critical, support
for doing this based on the properties of this type is poor, and it's
not easy to implement this correctly, so it seems reasonable to high-
light the problems with this in the specification, and otherwise try
to get it out of sight as much as possible. Ideally I'd like this the
item removed from the Message Length section, and perhaps recommend
to close the connection upon sight of a response where it would have
applied, or require to read until the connection is closed, possibly
due to a timeout; but I don't know whether this would break any impor-
tant real-world setup.
Björn Höhrmann · ·
Weinh. Str. 22 · Telefon: +49(0)621/4309674 ·
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · 

Received on Monday, 19 November 2007 04:47:25 UTC