[Bug]: Linearized PDF fully downloaded on load despite working Range support #20753

Attach (recommended) or Link to PDF file

https://game.alpha-infinity.fr/pdf

(PDF 327f11d70aecae9c6bfaf0936cf2790b [1.7 - / -])

Web browser and its version

Mozilla Firefox 147.0.4 - Chrome 139.0.7258.127

Operating system and its version

Ubuntu 24.04 TLS

PDF.js version

PDF.js: 5.4.445 [ec5330f] (tried 5.4.624 as well)

Is the bug present in the latest PDF.js version?

Yes

Is a browser extension

No

Steps to reproduce the problem

1. Build or use the generic viewer (web/viewer.html) from PDF.js
2. Edit web/viewer.mjs to serve a linearized PDF over HTTP with Accept-Ranges: bytes, Proper Content-Length, Correct handling of Range: bytes=... Valid 206 Partial Content + Content-Range and No Content-Encoding (achieved all of that, on my demo, using BinaryFileResponse from latest Symfony)
3. The PDF must be properly linearized - did it with qpdf --linearize then checked with qpdf --show-linearization / qpdf --check
4. Let range and stream enabled / autofetch disabled (althrough I tried different variations of theses options)
5. Open DevTools - Network tab

What is the expected behavior?

Since

• The PDF is linearized (qpdf --check file.pdf)
• Range requests are fully supported
• disableAutoFetch is set to true

I expect only the byte ranges necessary to render page 1 (and possibly minimal surrounding structures) to be requested.
The remainder of the document should only be fetched upon user interaction (e.g. scrolling to later pages), but it is even possible with PDF.js ?

What went wrong?

• On page load, the first request appears to download the full document before any further interaction
• Multiple 206 requests are triggered immediatly - the cumulative bytes ranges effectively cover the entire file

Link to a viewer

https://game.alpha-infinity.fr/pdfjs/web/viewer.html

Additional context

I have several questions about how this mechanism is intended to work in practice:

When operating with HTTP range requests, my understanding is that the initial request is typically a HEAD request intended only to retrieve metadata such as the Content-Length, without downloading the actual content — unless I am misunderstanding how PDF.js handles the initial negotiation phase.

1. Could you confirm whether this assumption is correct in the context of PDF.js’ network layer, or whether the library intentionally performs an initial GET request instead of HEAD, even when range support is available ?
2. Is disableAutoFetch intended as a hard guarantee against proactive fetching, or only a best-effort optimization?
3. Can you review my example (viewer.html url above) and determine whether my "PDF served with HTTP" implementation and the test PDF are correctly configured for optimal range-based loading.
4. Does PDF.js really handle PDF loading upon user scrolling ? Note: The primary use case is opening the PDF at an arbitrary page. For instance, if the URL requests page 100, the viewer should load only page 100 and its nearby pages, while deferring the rest until the user navigates to them. But is it really possible with PDF.js ?
5. Assuming it’s possible to enforce strict page-on-demand loading, is there a mechanism to still allow full-text search across the entire PDF without preloading all pages ?
6. I am using the standard viewer with its full-featured UI (full-text search, thumbnails, printing, zoom). Can this system support strict page-on-demand loading, or do these features inherently require preloading larger portions of the PDF?

I have reviewed various discussions regarding what PDF.js can or cannot do in terms of partial loading and on-demand fetching. However, the information I found is often inconsistent or even contradictory. Before evaluating alternative solutions, I wanted to reach out directly to clarify the expected and supported behavior.

Some of our PDFs can be quite large, and they will soon be served from an S3-compatible object storage. Since this storage model incurs costs per request and per transferred data volume, unnecessary full downloads would represent non-negligible operational costs.

I would therefore like to better understand whether strict page-on-demand loading is realistically achievable with PDF.js under the right structural conditions, or whether full-document fetching is effectively unavoidable in certain scenarios.