12

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?

LS_ᴅᴇᴠ
  • 10,823
  • 1
  • 23
  • 46

1 Answers1

15

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

PoByBolek
  • 3,775
  • 3
  • 21
  • 22
  • 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! – LS_ᴅᴇᴠ Aug 21 '13 at 15:56
  • BTW is it OK to send multiple responses with individual range? Also as asked by @LS_ᴅᴇᴠ Is it OK to send all the ranges combined? i.e. 100-200, 300-400, 500-600 ==> 100-600? – iammilind Feb 08 '20 at 04:08
  • @iammilind look at [RFC 7233](https://tools.ietf.org/html/rfc7233#section-4.1), 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. – PoByBolek Feb 09 '20 at 22:52
  • 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. – iammilind Feb 09 '20 at 23:23
  • @iammilind Still quoting from [RFC 7233](https://tools.ietf.org/html/rfc7233#section-4.1) 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 ;) – PoByBolek Feb 10 '20 at 19:28