Progressive rendering not working

[lucaong]

Attach (recommended) or Link to PDF file here:

Configuration:

• Web browser and its version: Chrome 65.0.3325.181
• Operating system and its version: Mac OSX 10.13.3
• PDF.js version: 2.0.449
• Is a browser extension: no

What is the expected behavior?

I have a linearized PDF, and a server returning accept-ranges: bytes. I expect the PDF to be progressively loaded/rendered, and to observe Range requests with 206 response codes, but instead no Range request is made, and the whole PDF is loaded and rendered in bulk.

I read a lot of other issues and responses related to Range requests, but I still cannot find what is wrong in my setup. CORS headers are OK, Accept-Ranges header is returned by the server, Range requests are supported (as tested with CURL).

Two specific things in my setup are:

• accept-ranges is lower case (PDF is on Google Cloud Storage). But headers should be case insensitive.
• The original request for the PDF responds with a 302 redirect to the actual file URL. Could this confuse PDFJS, as the redirect does not contain accept-ranges?

As you can see, the Accept-Ranges header is properly returned:

Any idea?

[Gabri-connect]

bump - Having same issue

[Snuffleupagus]

Unfortunately it's simply impossible for anyone to help with only a description/screen-shot of the problem, please see https://github.com/mozilla/pdf.js/blob/master/.github/CONTRIBUTING.md (emphasis mine):

If you are developing a custom solution, first check the examples at https://github.com/mozilla/pdf.js#learning and search existing issues. If this does not help, please prepare a short well-documented example that demonstrates the problem and make it accessible online on your website, JS Bin, GitHub, etc. before opening a new issue or contacting us on the IRC channel -- keep in mind that just code snippets won't help us troubleshoot the problem.

[angel-langdon]

@timvandermeij @Snuffleupagus @lucaong Hi, I know what the problem is here.

Yesterday I was implementing Range Requests using FastAPI from Python. This framework uses Starlette under the hood and Starlette sends headers always lower-case (as the example).

This is causing to not work properly Range-requests due to case-sensitive headers implementation of PDF.js, could you please fix this?

According to RFC 7230 (HTTP/1.1):

Each header field consists of a case-insensitive field name
followed by a colon (":"), optional leading whitespace, the field
value, and optional trailing whitespace.

https://www.rfc-editor.org/rfc/rfc7230#section-3.2

Also, RFC 7540 (HTTP/2):

Just as in HTTP/1.x, header field names are strings of ASCII
characters that are compared in a case-insensitive fashion.

https://www.rfc-editor.org/rfc/rfc7540#section-8.1.2

[kentingnguyen]

bump - I'm also running into this issue with Java Spring with Apache tomcat, which also sends headers as lower-case.

The code that seems to check the response header is this, and I didn't see any modifications to the header casing before it goes into the function

https://github.com/mozilla/pdf.js/blob/master/src/display/network_utils.js

function validateRangeRequestCapabilities({
...

if (getResponseHeader("Accept-Ranges") !== "bytes") {
   return returnValues;
 }

However, based on this issue, I'm also seeing conflicting information on whether it works with lowercase or not.
#11174

Could we get a confirmation one way or another on whether lower-case headers don't work and should be supported according to the RFC specs?

[angel-langdon]

Could we get a confirmation one way or another on whether lower-case headers don't work and should be supported according to the RFC specs?

@kentingnguyen I can confirm you that lowercase headers do not make a difference. I was able to achieve progressive rendering by correctly implementing my backend logic

Related issue #14514

My backend implementation in Python using range requests, maybe you can translate it to Java
https://stackoverflow.com/a/71309270/12234006

Another related issue
wojtekmaj/react-pdf#419 (comment)