Refused to get unsafe header "Content-Range"

[Jonathan Readman]

Hi

I am receiving the following error when loading the PDFTron HTML 5 viewer:

Refused to get unsafe header "Content-Range"

I've tried adding this header type within the config but still see the same error.

What is surprising me the most is I do not use the xod format of documents and haven't configured the viewer to stream files. I simply pass a pdf file from an azure blob storage.

Can you tell me how I can configure PDFTron to ignore the content-range header or tell it I don't want a streaming request?

Thanks in advance,
Jonathan

[Justin Jung]

Hello,

It may be related to cross origin issues, and you could try exposing Content-Range header in your server explicitly.

The issue posted here seems similar, and resolved by exposing the header. See here for details: https://github.com/mozilla/pdf.js/issues/3150#issuecomment-17582371

Alternatively, you could pass the option useDownloader:false so that range requests aren't made. Just note that this may increase the load time for larger documents.

Justin Jung

Software Developer

PDFTron Systems Inc.

[Jonathan Readman]

Hi

We enabled that header to be accepted on the server and are no longer seeing the content-ranger exception thrown. 

However, we're now seeing a performance issue during the initialisation stage. It seems to be taking longer to load the viewer.

I have tried useDownloader:false as suggested but it seemed to have no effect and continued to attempt to load the document incrementally.

The following shows that it is still attempted to download the file incrementally

I am also seeing pdfnet.res take 16.51 seconds to load when inspecting the network tab in chrome.

Any ideas why accepting the content-range header on the server would suddenly cause this performance issues?

Thanks,

Jonathan

[Justin Jung]

Could you resend us the screenshot? It seems like it didn't get uploaded properly.

To clarify, previously you were not able to load the document at all, but after enabling the header it can be loaded?

Or, you saw the error but the document was still loaded, now after fixing the header it's even slower?

Also, which version of WebViewer are you using?

[Jonathan Readman]

Hi Justin

I've tried to upload the file via a separate message.

To confirm, we saw the error but the document was still loaded, now after fixing the header it's even slower.

We're using version 6.7.1.59452

Thanks,
Jonathan

[Justin Jung]

It seems like the image didn't get sent again.

We just see the following image: 

Can you send us the document that you are trying to load as well as the WebViewer constructor call that you are making?

Also, 6.7.1 is the version of PDFNet that you are using. Could you check your WebViewer version as follows? https://groups.google.com/d/msg/pdfnet-webviewer/C4nmuak9Zbo/0r1peW1PTckJ

[Jonathan Readman]

The image that is failed to load shows the following message in the console window:

Could not use incremental download for url https://voattachmentdevelop.blob.core.windows.net. Reason: The file is not linearized.

I am also seeing PDFWorker.pexe take 17.46s to load.

The version is: 3.0.0

Constructor below (Stripped out license):

var myWebViewer = new PDFTron.WebViewer({

            path: '../PDFTronContent/lib',

            type: 'html5',

            l: 

            documentType: '@Html.Raw(Model.DocType)',

            initialDoc: '@Html.Raw(Model.URL)',

            documentId: '@Html.Raw(Model.VersionId)',

            enableAnnotations: true,

            config: "../PDFTronContent/config.js",

            serverUrl: "/MarkUp",

            pdfnet: true,

            custom: JSON.stringify(customArgs),

      useDownloader:false

        }, viewerElement);

[Justin Jung]

Are you using the full version of PDFNet or the lean version? If you are not sure, you can check the size of the PDFWorker.pexe file. If it's less than 10MB, it's a lean version.

If you don't need to use any of the features of the full version, we would recommend using the lean version.

You can download the lean version here: https://www.pdftron.com/webviewer/download.html

To confirm, this issue only occurs in the first time when loading? 

After the worker is cached, how long does the initial load take?

[Jonathan Readman]

PDFWroker.pexe is coming down at 8.8mb so must be the lean version.

We've gone back to your original suggestion and added useDownloader:false but also set streaming:true which bypasses the part of the code that checks if the HTTP code is a 206. We've seen the performance improve from doing this.

Can you confirm if this is recommended?

[Justin Jung]

Yup! Doing this shouldn't have any bad side effects :)