Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
dchandekstark opened this issue Apr 13, 2016 · 1 comment

Comments

@dchandekstark
Copy link
Member

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.

@dchandekstark dchandekstark changed the title DownloadController does not properly handle Range requests with multiple byte ranges Hydra::Controller::DownloadController returns only first range of valid multi-range request Apr 13, 2016
@dchandekstark dchandekstark changed the title Hydra::Controller::DownloadController returns only first range of valid multi-range request Hydra::Controller::DownloadController incorrectly handles multi-range request Apr 13, 2016
@electrickite
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Backlog
Development

No branches or pull requests

2 participants