Hydra::Controller::DownloadController incorrectly handles multi-range request

[dchandekstark]

We have observed with IE 10 and 11 requests for PDF files Range headers like:

Range: bytes=846336-846847, 846848-847359, 847360-847871 [...]

The current code inherited from 7.x expects only one range so only sends back the first range AFAICT (splits on "-", takes first two values and converts to ints; oddly "100, 101".to_i == 100). It appears that this response is not expected by the client and causes corruption, although this is not certain. In any case, it seems preferable to return the entire entity in this case

Note: It appears the Fedora 4 simply returns the entire entity (as permitted by HTTP/1.1) when multiple byte-ranges are specified. Perhaps Hydra could simply pass the Range value through as-is instead of parsing it, then set the Content-Range and Content-Length response headers based on those header in the Fedora response.

[electrickite]

Chiming in to note that I have also observed this behavior for video files downloaded from a Hydra application (Sufia 7) by Safari on both iOS and macOS. QuickTime will apparently issue multiple range requests to download a video file. This causes the browser to load a "player" but never download the video file for playback.

From http://stackoverflow.com/a/28779883

First, the Safari Web Browser requests the content, and if it's an audio or video file it opens it's media player. The media player then requests the first 2 bytes of the content, to ensure that the Webserver supports byte-range requests. Then, if it supports them, the iPhone's media player requests the rest of the content by byte-ranges and plays it.