Browser caching does not work for the first range request on Chrome and Safari

Dear community,

When one activates range requests with disableAutoFetch: true and disableStream: true and http server configured to cache contents with public, max-age=31536000, immutable, browser caching does work on Chrome, nor on Safari.

But the first range request return a code 200 and is not cached by the browser, until all the ranges has been download.

Attach (recommended) or Link to PDF file here: not file specific, but one can use https://public.fays.io/public/580af700-5f79-44c4-8a0c-f7e976ee528f.pdf

The server configuration is:

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, HEAD, PUT, POST
Access-Control-Expose-Headers: Accept-Ranges, Content-Range, Content-Length, x-amz-request-id, x-amz-id-2, ETag
Access-Control-Max-Age: 31536000
Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
Cache-Control: public, max-age=31536000, immutable

Configuration:

Web browser and its version: Chrome Version 80.0.3987.116. Firefox does not yet cache range requests, so it is out of scope.
Operating system and its version: mac os x 10.15.3 
PDF.js version: 2.2.228
Is a browser extension: no

Steps to reproduce the problem:

1. Clear the browser cache
2. Go to https://app.fays.io/bf205bf6-43d2-4140-8140-ab4b6f48c2a5 and open the developper tool. This viewer should work like the integrated viewer of PDF.JS
3. Refresh the tab

What is the expected behavior? The expected behavior is that the browser caches all the HTTP requests, including the first one with response code 200.

What went wrong? After step 3., one can see in the developer tool that the range requests have been cached but not the first request.

The first request has specific header for CORS:

:authority: public.fays.io
:method: GET
:path: /public/2ce2766d-b491-43a0-a0a9-96c56c2bd667.pdf
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7,de;q=0.6
if-modified-since: Sun, 23 Feb 2020 23:43:01 GMT
if-none-match: "dd09a498518c55f91fe48b29bec2ffde"
origin: https://app.fays.io
range: bytes=0-196607
referer: https://app.fays.io/bf205bf6-43d2-4140-8140-ab4b6f48c2a5
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: same-site
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.116 Safari/537.36

The request is not cached by the browser since PDF.JS cancels the first request. https://github.com/mozilla/pdf.js/blob/93aa613db7a874e6ed964f394241605d5586c142/src/display/fetch_stream.js#L155-L157

**Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension): ** https://app.fays.io/bf205bf6-43d2-4140-8140-ab4b6f48c2a5

Best, A.

[Snuffleupagus]

Still, the first request is an option if the user can ensure by itself that validateRangeRequestCapabilities is always true.

You want to trust the server, rather than the user here[1], to avoid a support nightmare later on. As was clearly mentioned in https://github.com/mozilla/pdf.js/issues/11624#issuecomment-590508658 we definitely do not want any foot guns in the options here, hence that won’t happen!

Besides, it’s really not at all correct to make the changes you’re suggesting since it’d make PDFFetchStreamReader unable to read any data (which is bound to break lots of other things).

Therefore, it will be nice to have a way to override this part easily outside PDF.JS but I don’t know how to do it properly. Can one extends PDFFetchStreamReader?

No, that’s considered internal functionality and it’s consequently not exposed in the public API. (You’d need to fork the code, but as I’ve tried to explain multiple times the changes you’re suggesting aren’t really a good idea.)

The “correct” way of handling special cases, with regards to fetching of data, would be to utilize PDFDataRangeTransport instead. That allows completely custom data delivery, that you thus can implement in what ever way you want/need in your case (it’s being used in the PDF Viewer that’s built-in to the Firefox browser); see https://github.com/mozilla/pdf.js/issues/11453#issuecomment-569347187 for some relevant links.

This issue really ought to remain closed. /cc @timvandermeij

---

[1] Previous experiences have shown that users may, more often than you’d like, set certain options without always fully understanding the ramifications of doing so.

[timvandermeij]

Yes, it’s part of the public API; see also https://github.com/mozilla/pdf.js/blob/12400489c2f2b3f93fe394806a5f276c1d588161/src/display/api.js#L177

Closing as answered since there is not really anything we can/should do here.