Why is the HTTP response not giving me my specified range of data?

Question

So I am grabbing an HTTP object such as a .png from a url using the Range property. I find the content-length of the whole object and then I split up the starting bytes and ending bytes of each range. Everything works fine up until the last range.

// My specified range is:
HttpURLConnection urlConnection = (HttpURLConnection)url.openConnection();
urlConnection.setRequestProperty("Range", "bytes=22128-27657");

// It returns (Response Header):
HTTP/1.1 206 Partial Content
Thu, 17 Mar 2016 17:04:34 GMT
Downloaded Size: 5533
bytes
5529
bytes 22128-27656/27657 // !!! - Incorrect
Keep-Alive

However, on every other range, I am getting the data I ask for:

// My specified range is:
HttpURLConnection urlConnection = (HttpURLConnection)url.openConnection();
urlConnection.setRequestProperty("Range", "bytes=5533-11066");

// It returns (Response Header):
HTTP/1.1 206 Partial Content
Thu, 17 Mar 2016 17:04:34 GMT
Downloaded Size: 5533
bytes
5529
bytes 5533-11066/27657 // !!! - Correct
Keep-Alive

What is happening?

Answer 1

The value of the Content-Range header is defined as (abbreviated):

 Content-Range       = byte-content-range
 byte-content-range  = bytes-unit SP byte-range-resp
 byte-range-resp     = byte-range "/" ( complete-length / "*" )
 byte-range          = first-byte-pos "-" last-byte-pos
 complete-length     = 1*DIGIT

and section 2.1 says:

 first-byte-pos      = 1*DIGIT
 last-byte-pos       = 1*DIGIT

The first-byte-pos value in a byte-range-spec gives the byte-offset of the first byte in a range. The last-byte-pos value gives the byte-offset of the last byte in the range; that is, the byte positions specified are inclusive . Byte offsets start at zero.

So with a length of 27657 , positions are 0-27656 .

When you ask for 22128-27657 , you are asking for more bytes than are available, and the response is truncated to what is actually available.

Answer 2

Byte ranges are 0-indexed. With bytes=22128-27657 , you're asking for the 22129th byte through the 27658th byte, but there are only 27657 bytes. Both of your examples are behaving correctly.