Byte-Range Requests

byte-range

What Are Byte-Range Requests?

Byte-Range Requests occur when a client asks the server for only a portion of the requested file. The purpose of this is essentially to conserve bandwidth usage by avoiding the need to download a complete file when all that is required is a small section. In order to initiate a byte range request the client will use the range request header to specify what byte range it is requesting (e.g Range: bytes=0 - 499). Additionally, the server must contain the Accept-Ranges field in its response header (e.g Accept-Ranges: bytes) .

There are two possible status codes that can occur when a client makes a byte-range request.

  • 206 Partial Content which indicates that the request byte range was successfully sent
  • 416 Requested Range Not Satisfiable which indicates that the range was invalid.

What Are Byte-Range Requests Used For?

Byte-Range Requests are used primarily for requesting particular sections of large media files. As mentioned above, they are used largely to conserve bandwidth and save time. Byte-Range Requests can also be used by multihomed clients (computers with multiple IP addresses connected to one network) to download a file over more than one connection at the same time.

For example, let’s say a client only needs a small section of a large media file. Rather than downloading the complete file, the client can use a byte range request and download only the required portion. This can also come in useful for an large download that has been interrupted. Through using a byte-range request, you have the ability to pick up the download at the point when it was interrupted. Another use-case may be that a client wants to download only one important page of a PDF document instead of the document in its entirety.

Examples

An example request that a client may make for a byte range would resemble the following for the first 500 bytes:

Range: bytes=0-499

While the next 500 bytes would look like:

Range: bytes=500-999

Using the above example, the 500 value is known as the first-byte-pos and the 999 value is the last-byte-pos. The last-byte-pos cannot be less than the first-byte-pos otherwise the server will return a 416 error. In the case that the last-byte-pos is not included or is larger than the file in question, the server interprets that the client wants all the data from the first-byte-pos onward.

There are also other byte request variations that can be used such as:

  • A request for the last 500 bytes: bytes=-500
  • A request for the first and last byte: bytes=0-0,-1

Conclusion

For purposes of saving bandwidth and time, using byte-range requests can be an efficient method of quickly retrieving the information you want and nothing more. This feature becomes increasingly important as the size of the requested file increases, thus using more resources to fully download.

For more information about range requests, visit the ietf.org range request specification document.

3 Comments

  1. David Rueter

    1) Does KeyCDN support byte-range requests?

    2) Can KeyCDN be configured with a pull zone that supports byte-range requests even though the origin does not support byte-range requests? (i.e. the CDN would cache the file, then serve up byte-ranges as requested)

    1. KeyCDN

      Yes, KeyCDN supports byte-range requests. We fully cache an asset and support byte-range requests regardless of the origin server.

      1. David Rueter

        Great! FYI when publishing podcasts, iTunes requires / encourages byte-range support. Using KeyCDN in front of a web server that does not support byte-range requests seems like it could be a good solution. Also FYI, other CDN’s I have looked at (MaxCDN, Softlayer, and others) either don’t support byte-range requests, or don’t support byte-rage requests unless the origin server does.

Leave A Comment?