Chrome 39 seems to incorrectly cache RangeResponses

[CodingFabian]

Message: Unexpected server response (206) while retrieving PDF.

It looks like either PDF.js does something strange, or there is a regression in Chrome 39 (Version 39.0.2171.65 (64-bit)).
Sometimes I am getting a partial response for the first request. If I have dev-tools with the cache override open, this does not happen at all.
If I allow caching then chrome seems to mix up the responses sometimes.

Might be a regression of the streaming implementation?
Right now I need to add Chrome 39 to checkRangeRequests() in Compatibility.js

[CodingFabian]

it even reproduces locally on the tracemonky paper.

[CodingFabian]

Here is how a clean cache load looks like

And here is how then a reload (keeping the cache, e.g. enter in the url bar) looks like

[Rob--W]

@CodingFabian Could you paste the headers of an allegedly cached response?
And also provide a script that starts a local server with the caching headers that you used to generate the screenshots.

[CodingFabian]

@Rob--W no need for a script. this is default behaviour of pdf.js here.
checkout master and run node make server

Here the first request when working

Remote Address:127.0.0.1:8888
Request URL:http://localhost:8888/web/compressed.tracemonkey-pldi-09.pdf
Request Method:GET
Status Code:200 OK
Request Headersview source
Accept:*/*
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:no-cache
Connection:keep-alive
Host:localhost:8888
Pragma:no-cache
Referer:http://localhost:8888/src/worker_loader.js
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36
Response Headersview source
Accept-Ranges:bytes
Connection:keep-alive
Content-Length:1016315
Content-Type:application/pdf
Date:Mon, 01 Dec 2014 11:40:01 GMT

and here when not:

Remote Address:127.0.0.1:8888
Request URL:http://localhost:8888/web/compressed.tracemonkey-pldi-09.pdf
Request Method:GET
Status Code:206 Partial Content
Request Headersview source
Accept:*/*
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Host:localhost:8888
Range:bytes=0-786431
Referer:http://localhost:8888/src/worker_loader.js
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36
Response Headersview source
Accept-Ranges:bytes
Connection:keep-alive
Content-Length:786432
Content-Range:bytes 0-786431/1016315
Content-Type:application/pdf
Date:Mon, 01 Dec 2014 11:41:32 GMT

so from what it looks like there is already something odd when the very first request is visible in the console.

[yurydelendik]

@CodingFabian I had some time to bisect:

You are probably looking for a change made after 292738 (known good), but no later than 292753 (first known bad).
NOTE: There is a Blink roll in the range, you might also want to do a Blink bisect.
CHANGELOG URL:
  http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/trunk/src&range=292738%3A292753

Which kinda points to https://chromium.googlesource.com/chromium/src.git/+/439a05cd87fe1f880b896bd7b154454299355899%5E%21/

https://code.google.com/p/chromium/issues/detail?id=407923

[yurydelendik]

https://code.google.com/p/chromium/issues/detail?id=444659

[CodingFabian]

yeah good find. though quite annoying, because pdf.js should then disable ranges for confirmed chrome versions (39?) (similar to the safari disable)

[yurydelendik]

pdf.js should then disable ranges for confirmed chrome versions (39?) (similar to the safari disable)

Yes, we should, until the issue will be sorted out, at least for versions 39-41. PR is welcome. STR in the chromium issue shall be corrected as well.

[CodingFabian]

Ok, will do that.

[CodingFabian]

while i was waiting for a clearer confirmation from chrom(e|ium), I think its safe to assume we should disable range requests for chrome > 39.

[Rob--W]

@CodingFabian Wouldn't it be better to detect response code 206 and handle that appropriately instead of disabling range requests all together?

[CodingFabian]

that would be better and quite complicated. for safari and android we already disable it globally because the quirks are complicated to detect.
Its broken in chrome 39+ until fixed and its easy to turn it off. And when looking at the chrome bugs, its even not 100% clear whats broken, so I would not know how we would actually work around that.

[Rob--W]

Disabling range requests has implications for perceived performance, especially for huge documents and/or slow connections. That's why I'm opposed to disabling range requests unless there is no alternative.

The first request is only used to get the file's metadata, and if range requests are supported, the request is aborted. However, due to the fact that Chrome 39+ replies with status 206 instead of 200, PDF.js bails out and reports an error. Since the metadata is available (range requests is supported as implied by status code 206, and also content-length), I think that it is feasible to reliably detect this bug and treat it appropriately (e.g. continue fetching ranges).

[CodingFabian]

feel free to make a PR.
I am pretty aware of the implications. I was actually surprised nobody besides noticed the problem so far. We got quite a few customer complaints when they upgraded to chrome 39.
I fear in real deployments of custom pdf.js versions, the server does not support range requests.
right now we deployed a quick fix to our load balancer disabling range requests, which has the implications you describe.

MY PR does a nicely coupled clean hotfix in compatibility.js, which at least makes pdf.js work again :)

[Rob--W]

@CodingFabian See PR #5603.

[timvandermeij]

Fixed by #5598.