HTTP/1.1 response to multiple range

Question

While writing my HTTP/1.1 server, I get stuck dealing multiple ranges request.

Section 14.35.1 of RFC 2616 refers some examples but doesn't clarify server behaviour. For instance:

GET /some/resource HTTP/1.1
...
Range: bytes=200-400,100-300,500-600
...

Should I return this exact sequence of bytes? Or should I merge all ranges, sending 100-400,500-600? Or sending all in between, 100-600?

Worst, when checking Content-Range response header (Section 14.16), only a single range may be returned, so I wonder how would a server response to example in Section 14.35.1 bytes=0-0,-1!!!

How should my server handle such requests?

Nevarez

Answer 1

I just had a look at how other servers that support the Range header field might respond and did a quick curl to example.com:

~# curl -s -D - -H "Range: bytes=100-200, 300-400" http://www.example.com
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5
Content-Length: 385
Server: ECS (fll/0761)


--3d6b6a416f9b5
Content-Type: text/html
Content-Range: bytes 100-200/1270

eta http-equiv="Content-type" content="text/html; charset=utf-8" />
    <meta name="vieport" content
--3d6b6a416f9b5
Content-Type: text/html
Content-Range: bytes 300-400/1270

-color: #f0f0f2;
        margin: 0;
        padding: 0;
        font-family: "Open Sans", "Helvetica
--3d6b6a416f9b5--

Apparently, what your looking for is the Content-Type: multipart/byteranges; boundary response header. Googling exactly that turned up a W3C document with appendices to RFC 2616

When an HTTP 206 (Partial Content) response message includes the content of multiple ranges (a response to a request for multiple non-overlapping ranges), these are transmitted as a multipart message-body. The media type for this purpose is called "multipart/byteranges".
The multipart/byteranges media type includes two or more parts, each with its own Content-Type and Content-Range fields. The required boundary parameter specifies the boundary string used to separate each body-part.

So there you go.

By the way, the server at example.com does not check for overlapping byte ranges and sends you exactly the ranges that you requested...

Artair

You hit the point! I confess I didn't try it because I was afraid that it could result in some server specific behavior, and not any standard. Thank you! – Sashenka

BTW is it OK to send multiple responses with individual range? Also as asked by @Nevarez Is it OK to send all the ranges combined? i.e. 100-200, 300-400, 500-600 ==> 100-600? – Trista

@Trista look at RFC 7233, which defines the 206 Partial Content response status code: "When multiple ranges are requested, a server MAY coalesce any of the ranges that overlap, ..." But you can only ever send one response to a request. – Artair

Thanks. But what if a server may not be supported with multiple ranges, but only single range? Also if the ranges are not overlapping, still can server send any combined range, which a client didn't ask for? I am asking from server implementation perspective. – Trista

@Trista Still quoting from RFC 7233 and the same sentence as before: "When multiple ranges are requested, a server MAY coalesce any of the ranges that overlap, or that are separated by a gap that is smaller than the overhead of sending multiple parts, regardless of the order in which the corresponding byte-range-spec appeared in the received Range header field." If you are asking from an implementation perspective, you should really go ahead and read that RFC ;) – Artair