Subject: draft-ietf-httpbis-p5-range-21, "3.2 416 Requested Range Not Satisfiable"

From: Julian Reschke <[email-masked]>
Date: Wed, 24 Oct 2012 14:21:03 +0200

<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p5-range-21.html#status.416>:

"When this status code is returned for a byte-range request, the 
response SHOULD include a Content-Range header field specifying the 
current length of the representation (see Section 5.2). This response 
MUST NOT use the multipart/byteranges content-type. For example,"

What is this "MUST NOT" about? Are there clients that will ignore the 
status code and assume success if they see the expected content-type?

Best regards, Julian

---

From: Zhong Yu <[email-masked]>
Date: Wed, 24 Oct 2012 10:52:03 -0500

Wouldn't "Content-Type: multipart/byteranges" cause confusions if it's
used anywhere other than in a 206 response?

Suppose a representation itself has the content type of "multipart/byteranges"

    Get /slivers HTTP/1.1

    HTTP/1.1 200 OK
    Content-Type: multipart/byteranges

That's pretty confusing for observers. Even more confusingly

    Get/slivers HTTP/1.1
    Range: bytes=0-499

    HTTP/1.1 206 Partial Content
    Content-Type: multipart/byteranges
    Content-Range: bytes 0-499/1234

Maybe we should strongly discourage the use of multipart/byteranges in
any application except in a HTTP 206 response.

Zhong Yu

On Wed, Oct 24, 2012 at 7:21 AM, Julian Reschke <[email-masked]> wrote:
> "When this status code is returned for a byte-range request, the response
> SHOULD include a Content-Range header field specifying the current length of
> the representation (see Section 5.2). This response MUST NOT use the
> multipart/byteranges content-type. For example,"
>
> What is this "MUST NOT" about? Are there clients that will ignore the status
> code and assume success if they see the expected content-type?
>
> Best regards, Julian
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 24 Oct 2012 17:58:20 +0200

On 2012-10-24 17:52, Zhong Yu wrote:
> ...

Potentially.

On the other hand, it's very strange to special case one specific media 
type, when the media type of the content should be completely orthogonal 
to the response semantics.

Best regards, Julian

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 24 Oct 2012 19:58:59 +0000

I've always considered multipart/byteranges to be less than optimal 
design for the problem.

A server should be able to send the byte ranges coalesced in a single 
message body, since it advertised the ranges coming back it's possible 
to unpick it, and doesn't then require the part separators etc.

that way you don't need to overload the Content-Type which then removes 
your ability to transfer the actual content type (although presumably 
this has been communicated earlier).

Does anyone actually use multiple ranges?  

------ Original Message ------
From: "Zhong Yu" <[email-masked]>
To: "Julian Reschke" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 25/10/2012 4:52:03 a.m.
Subject: Re: draft-ietf-httpbis-p5-range-21, "3.2 416 Requested Range 
Not Satisfiable"

---

From: Zhong Yu <[email-masked]>
Date: Wed, 24 Oct 2012 16:00:04 -0500

On Wed, Oct 24, 2012 at 2:58 PM, Adrien W. de Croy <[email-masked]> wrote:
> I've always considered multipart/byteranges to be less than optimal design
> for the problem.
>
> message body, since it advertised the ranges coming back it's possible to
> unpick it, and doesn't then require the part separators etc.

That doesn't work for other range units though (but does anyone
actually use non-byte units?)

I agree multipart sucks. It was probably designed for human eyes? It's
hard for programming, both in generating and in parsing.

>
> that way you don't need to overload the Content-Type which then removes your
> ability to transfer the actual content type (although presumably this has
> been communicated earlier).
>

It doesn't seem necessary at all. The client can always send multiple
requests, each for a single range; the overhead of multiple requests
is probably inconsequential compared to the bytes of the body.

> Subject: Re: draft-ietf-httpbis-p5-range-21, "3.2 416 Requested Range Not
> Satisfiable"
>>
>>> status

---

From: Julian Reschke <[email-masked]>
Date: Wed, 24 Oct 2012 23:04:33 +0200

> is probably inconsequential compared to the bytes of the body.

Well, we know that it *is* used.

Best regards, Julian

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 24 Oct 2012 21:07:09 +0000

------ Original Message ------
From: "Zhong Yu" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "Julian Reschke" <[email-masked]>;"[email-masked]" 
<[email-masked]>
Sent: 25/10/2012 10:00:04 a.m.
Subject: Re: draft-ietf-httpbis-p5-range-21, "3.2 416 Requested Range 
Not Satisfiable"
>actually use non-byte units?)

I've always considered any other range unit to be a Really Bad Idea 
which I hope never sees the light of day.  In fact I'd love to see the 
extensibility of Range deprecated.

there is always another way to do different types of range (e.g. pages, 
frames etc) which doesn't break everything (esp caches).

>hard for programming, both in generating and in parsing.
It's horrible to parse.  MIME multipart is not a good format for 
performance.