[Bug]: Unexpected behavior with Range requests

[NJUST-OpenLib]

Attach (recommended) or Link to PDF file

pdf is :
https://pub-e8e5b0f91de74680bb33f42c56c9d63e.r2.dev/%E5%A4%A7%E7%89%A9%E4%B8%8B%201-99.pdf

Web browser and its version

Firefox 136.0.1 (64 bit)

Operating system and its version

Windows 11 64bit professional edition

PDF.js version

5.0.375

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

Yes

Is a browser extension

No

Steps to reproduce the problem

Steps to Reproduce the Problem

1. Open Firefox and navigate to the official PDF.js demo:

   • [Mozilla PDF.js Viewer](https://mozilla.github.io/pdf.js/web/viewer.html)

2. Append the following URL parameter to load a PDF hosted on Cloudflare R2:

   ?file=https://pub-e8e5b0f91de74680bb33f42c56c9d63e.r2.dev/%E5%A4%A7%E7%89%A9%E4%B8%8B%201-99.pdf
   

   The final URL should look like this:

   https://mozilla.github.io/pdf.js/web/viewer.html?file=https://pub-e8e5b0f91de74680bb33f42c56c9d63e.r2.dev/%E5%A4%A7%E7%89%A9%E4%B8%8B%201-99.pdf
   

   • This PDF file is 68,927,756 bytes in size and is linearized (Fast Web View enabled).

3. Open the Firefox Developer Tools (F12) and go to the Network tab.

4. Set the filter to XHR or All to monitor network requests related to the PDF loading process.

5. Reload the page and observe the network requests:

   • You should see an initial 200 OK response for the full PDF file, which downloads the entire 68.93MB file.
   • After this, multiple 206 Partial Content responses follow, each requesting small chunks (66KB by default).

6. Change the CHUNK SIZE in pdf.js to a larger value (e.g., 1MB instead of 64KB).

   • Modify CHUNK_SIZE from:

     const DEFAULT_RANGE_CHUNK_SIZE = 65536; // Default: 64KB

     to:

    const DEFAULT_RANGE_CHUNK_SIZE = 65536*16; // 1MB

   • Reload the viewer and monitor the network activity again.
   • You will notice that total data consumption increases significantly (e.g., loading a 68MB PDF may now consume 130MB of network traffic).

---

What is the expected behavior?

1. Once the necessary metadata is retrieved, subsequent requests should only fetch the needed portions of the file rather than re-downloading large sections.
2. If the file is already fully downloaded via the initial 200 response, pdf.js should not continue making additional 206 Range Requests.

What went wrong?

Since the PDF is linearized (Fast Web View enabled), only the necessary metadata should be fetched first to allow incremental loading.
However, the viewer downloads the entire PDF file first and then still makes multiple Range Requests (206 responses).

Link to a viewer

https://mozilla.github.io/pdf.js/web/viewer.html?file=https://pub-e8e5b0f91de74680bb33f42c56c9d63e.r2.dev/%E5%A4%A7%E7%89%A9%E4%B8%8B%201-99.pdf

Additional context

No response

[Snuffleupagus]

pdf.js/src/display/api.js

Lines 203 to 212 in e37236e

	* @property {boolean} [disableStream] - Disable streaming of PDF file data.
	* By default PDF.js attempts to load PDF files in chunks. The default value
	* is `false`.
	* @property {boolean} [disableAutoFetch] - Disable pre-fetching of PDF file
	* data. When range requests are enabled PDF.js will automatically keep
	* fetching more data even if it isn't needed to display the current page.
	* The default value is `false`.
	*
	* NOTE: It is also necessary to disable streaming, see above, in order for
	* disabling of pre-fetching to work correctly.

[NJUST-OpenLib]

No matter how you set the program,

you should NOT Load the complete PDF once first and then load many fragments.

Because the complete PDF ALREADY
provides enough data. What's the purpose of sending a bunch of range requests?

it's obviously has problems and it has nothing to do with the settings.

[Snuffleupagus]

The extra range-requests are caused by the "bad" internal structure of your PDF document, since all /Page-objects are placed directly at the top-level of the /Pages-tree and trying to improve this one (bad case) case would thus break many other documents.

[NJUST-OpenLib]

Thanks, that's very helpful! I never noticed that before. Now I totally understand the reason and how it works. Sorry for taking up your time.