[Bug]: Large number of range requests triggered in master vs mozilla.github.io when loading a linearized PDF

[catmanjan]

Attach (recommended) or Link to PDF file

https://d2tkmshiozsr4v.cloudfront.net/documents/files/000/041/350/original/ad41798557504b40d26e11b4f059c0945bb5ca14/750614main_NASA_FY_2014_Budget_Estimates-508.pdf#disableAutoFetch=true&disableStream=true

Web browser and its version

Google Chrome

Operating system and its version

Windows 11

PDF.js version

master

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

Yes

Is a browser extension

No

Steps to reproduce the problem

0. Open your network inspector
1. Load the following URL: https://mozilla.github.io/pdf.js/web/viewer.html?file=https://d2tkmshiozsr4v.cloudfront.net/documents/files/000/041/350/original/ad41798557504b40d26e11b4f059c0945bb5ca14/750614main_NASA_FY_2014_Budget_Estimates-508.pdf#disableAutoFetch=true&disableStream=true
2. You will see 13 requests go to the cloudfront.net host, all various range requests to load the linearized PDF correctly (around 1.5MB downloaded)
3. Now try loading the same PDF using viewer.html from master, you will see over 200 range requests (around 15MB downloaded)

What is the expected behavior?

I am not sure if there is a bug in master or mozilla.github.io handling of linearized PDFs, mozilla.github.io seems to be working fine and it has less bytes over the wire which is preferred

What went wrong?

mozilla.github.io:

master:

Link to a viewer

No response

Additional context

No response

[Snuffleupagus]

WFM, since I cannot spot any difference between the two cases in quick testing (using both Mozilla Firefox 130 and Google Chrome 128).

Now try loading the same PDF using viewer.html from master,

Note that this uses a very simple web-server, which is not intended for production use, and that may perhaps be related here?

pdf.js/test/webserver.mjs

Lines 17 to 18 in f6b356e

	// PLEASE NOTE: This code is intended for development purposes only and
	// should NOT be used in production environments.

[catmanjan]

@Snuffleupagus just to confirm are you saying you are not seeing 200+ network requests in your own environment?

I am serving the PDF from my own server not the webserver bundled with PDF.js

[Snuffleupagus]

just to confirm are you saying you are not seeing 200+ network requests in your own environment?

I'm not, when testing using https://github.com/mozilla/pdf.js/blob/master/test/webserver.mjs

I am serving the PDF from my own server not the webserver bundled with PDF.js

Unfortunately it sounds like the problem might be with your server, which I don't think we can really help (much) with here.

[catmanjan]

@Snuffleupagus to rule out my server I added my domain to HOSTED_VIEWER_ORIGINS and I still get more requests from master compared to the one running on mozilla.github.io using the same PDF URL

Is there a way to tell what commit is running on mozilla.github.io?

[Snuffleupagus]

and I still get more requests from master compared to the one running on mozilla.github.io using the same PDF URL

Note that https://mozilla.github.io/pdf.js/web/viewer.html simply runs on a server provided by GitHub, since the demo viewer is hosted at GitHub Pages.

Is there a way to tell what commit is running on mozilla.github.io?

Yes, both the version number and commit hash is logged in the console (note the parenthesis at the end):

PDF 110dd61fd57444010b1ab5ff38782f0f [1.4 pdfeTeX-1.21a / TeX] (PDF.js: 4.5.162 [f6b356eff])

Generally though, the demo viewer always contains a GENERIC-build of the latest master branch.

[catmanjan]

I really don't know how to explain the variance I am seeing - where in PDF.js are the begin and end components of the range request generated?

[catmanjan]

@Snuffleupagus I finally figured this one out - I'm not sure how I even managed to get it working in the first place - looks like URL params are not read unless pdfBugEnabled is set to true - is that expected, and should the instance hosted on github have it set to false?

[Snuffleupagus]

[...] looks like URL params are not read unless pdfBugEnabled is set to true - is that expected, and should the instance hosted on github have it set to false?

Yes, outside of development mode that option must be manually enabled.
Please note: It's really not a good idea to enable pdfBugEnabled in production, since it'll allow an end-user to change various options which may significantly affect e.g. performance and functionality of the library.

Instead, calling PDFViewerApplication.open(...) with the options needed is a better solution; see also https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#file

Finally, please keep this in mind http://mozilla.github.io/pdf.js/getting_started/#introduction (emphasis mine):

The viewer is built on the display layer and is the UI for PDF viewer in Firefox and the other browser extensions within the project. It can be a good starting point for building your own viewer. However, we do ask if you plan to embed the viewer in your own site, that it not just be an unmodified version. Please re-skin it or build upon it.