Response to a Range request is invalid

[robbietjuh]

I've been looking into serving a very short and simple .mp4 video file through the uWSGI static files module. Works perfectly fine in Chrome but doesn't seem to work at all in Safari. This seems to be due to the required support for the Range-header by Apple (reference).

I stumbled upon the --honour-range option. The following output is with the option enabled.

The following shows a client requesting 0-1 bytes from the server. The server responds with Content-Length: 2 and Content-Range: bytes=0-1/7989608, which seems to be all fine and dandy. However, the content itself does not conform to the requested range:

GET /media/video.mp4 HTTP/1.1
Range: bytes=0-1

HTTP/1.1 206 Partial Content
Content-Type: video/mp4
Content-Length: 2
Content-Range: bytes 0-1/7989608
Last-Modified: Wed, 23 Aug 2017 00:29:16 GMT
X-ProxyInstance: fw02
X-AppInstance: web01

 ftypisomisomiso2avc1mp4freey?Xmdat? [.... ~125662 other chars]

After digging around in the source code I found this function to be at least mildly interesting: https://github.com/unbit/uwsgi/blob/master/core/protocol.c#L231

My C skills aren't to be written home about, so I'd love it if someone could have a look at this and maybe create a pull request.

[jeffsd]

I'm seeing the same thing, using a uWSGI with Python/Flask.
--honour-range is on in uwsg.ini

An additional twist; the file is served with an X-Sendfile header from Flask, to ask uWSGI to send.

NOTE: Chrome plays video from the start, but won't allow seeking.

[mattbadrabbit]

I can reproduce a bug with range requests when honour-range is enabled. I'm using uwsgi 2.0.15

curl 'http://example.com/somefile' --silent -H 'Range: bytes=-1'

gives the first 2 bytes of the file, instead of the last byte