Add support for Multi Range header #599

Closed
edhgoose opened this Issue Jun 14, 2012 · 8 comments

Comments

Projects
None yet
5 participants

As per the below Stack Overflow post, Connect doesn't currently support Range requests with multiple ranges, e.g. Range: bytes=1-1024,1025-2048

The Stack Overflow question also includes a rough (very rough) gist for a fix if you need one urgently!

http://stackoverflow.com/questions/11020374/why-does-internet-explorer-fail-to-download-a-pdf-using-nodejs-and-express/11033955

Member

tj commented Jun 14, 2012

thanks for opening the issue. that patch doesn't look correct though - we should be responding with multipart to satisfy the extra ranges

No worries, in hindsight the patch is obviously wrong, but it seems to work for our specific use case. I look forward to someone with a few more NodeJS smarts solving it for reals!

edhgoose closed this Jun 14, 2012

tj reopened this Jun 14, 2012

Member

tj commented Jun 14, 2012

I'll get to it when I can but it might be a bit

bf commented Aug 16, 2012

Unfortunately multi-range support is a huge issue when using the Adobe Reader PDF plugin when streaming PDF files via res.sendfile().

Adobe Reader will send requests with Range: bytes=1-1,1583255-1587350, and the current implementation of sendfile uses SendStream.prototype.send in send.js which in turn only uses the first of both ranges specified, namely 1-1. This means that res.sendfile() returns only the first byte of the file in question, and not the range more important for displaying a PDF file, 1583255-1587350.

So the node.js response generated via connect looks like this:

Content-Length:     1
Content-Range:      bytes 1-1/1587474

The specs for implementing multiple Content-Ranges are on w3.org and need to be implemented as multi-part responses. Quite a thing to do just in order to stream a PDF! ;-)

Btw: Varnish has had a related bug at https://www.varnish-cache.org/trac/ticket/788 .

bf commented Aug 16, 2012

I have now opened pull request to the send module which provides an easy workaround for this issue by disabling range requests for certain file types: https://github.com/visionmedia/send/pull/6/files

To circumvent this condition when serving PDF files with res.sendfile(), I have now disabled range requests (and the patched send module accepts this).

// Adobe Reader bug, weird range requests for example:
//      Range: bytes=1-1,3229472-3233567
res.header("Accept-Ranges", "none");

res.sendfile(file);
Range: bytes=1-1,3229472-3233567

I stumbled across this doing some googling on range requests ... for the edification of any future passersby, note that the range header in question is perfectly valid as per HTTP/1.1 and should result in a Content-Type: multiplart/byteranges; boundary=xxx response in which there are two parts delimited by the xxx boundary:

This is not an "Adobe Reader bug" ... it's a problem with the code responsible for reading and responding to the perfectly valid range request.

Contributor

jonathanong commented Oct 22, 2013

the static server uses send. can you guys move this issue to that repo? i think there is already one: visionmedia/send#20

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment