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!
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!
I'll get to it when I can but it might be a bit
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-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 .
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
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:
Content-Type: multiplart/byteranges; boundary=xxx
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.
the static server uses send. can you guys move this issue to that repo? i think there is already one: visionmedia/send#20