206 Partial Content is incorrectly implemented causing some video files (MP4) to fail. This is caused by the introduction of range headers in a567b6f in issue #2140

Expected behavior

According to RFC 2616, the byte-range-resp-spec should be (first-byte-pos "-" last-byte-pos).

For example, if the resource is of length 1234 and the range request is for bytes 500-, the range should be 500-1233/1234

If my resource is 229,255 bytes and I request it with:

Range: bytes=0-

I expect:

HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Range: bytes 0-229254/229255
Content-Length: 229255

Actual behavior

Currently, when my resource is 229,255 bytes and I request it with karma v1.2.0:

Range: bytes=0-

I am receiving:

HTTP/1.1 206 Partial Content
Content-Range: bytes 0-229255/229255

Few things are wrong here:

• Content-Range should be bytes 0-229254/229255 instead of 0-229255/229255
• Should return Accept-Ranges
• We should return Content-Length since it's recommended for application to implement according to RFC 2616.

Also I recommend we use range-parser for this.

Environment Details

Introduced in Karma v1.2.0. In v1.1.2, this is fine.

Fails in Chrome 52 and Chrome 53, in Mac OS X, Windows and Ubuntu.

Steps to reproduce the behaviour

1. Use files to serve a small MP4 asset in Chrome 52 or Chrome 53.
2. Asset will not load as range headers are wrong, this causes video not to play