W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2007

Re: NEW ISSUE: status of multipart/byteranges

From: Jamie Lokier <jamie@shareable.org>
Date: Mon, 19 Nov 2007 02:51:18 +0000
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: ietf-http-wg@w3.org
Message-ID: <20071119025118.GB8450@mail.shareable.org>

Bjoern Hoehrmann wrote:
> * Bjoern Hoehrmann wrote:
> >Apache 2.2.6 for example treats
> >
> >  POST / HTTP/1.1
> >  Host: example
> >  Content-type: multipart/byteranges;
> >    boundary=THIS_STRING_SEPARATES
> >  
> >  --THIS_STRING_SEPARATES
> >  ...
> >
> >as two requests, a zero-length POST and a --THIS_STRING_SEPARATES to
> >the root which it does not support (which seems to be a bug in itself).
> 
> Actually no, with neither Transfer-Encoding and Content-Length the
> message would be seen as having no body and the type would not affect
> the message length, so "If the message uses the media type ..." should
> really be "If a response uses the media type". This does not affect
> the rest of the issue though.

In RFC 2616, section 4.4, no mention is made of "206 responses", only:

    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 ultiple byte- range specifiers from a 1.1 client
    implies that the lient can parse multipart/byteranges responses.

This suggests that there might be other circumstances in which a
sender might know that a recipient can parse multipart/byteranges, not
specified in HTTP, otherwise this paragraph would be more specific
that it is only allowed in 206 responses to requests with Range.

A proxy cannot be expected to know what recipients can parse in
general.  They probably should always forward these messages, parsing
the boundaries.

Because "This media type MUST NOT be used unless the sender knows that
recipient can parse it", in the above POST example, any recipient of
this request should reject it as invalid, and because it does not
satisfy the basic rules for message length in section 4.4, responding
with an error and closing the connection without parsing any further
seems like the only safe response.

A server shouldn't parse the next request as if there's an empty body,
even if that's technically allowed, because it's a security hole, if
we believe there is a likelihood of proxies calculating the message
boundary differently when they forward it.

-- Jamie
Received on Monday, 19 November 2007 04:41:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:23 GMT