Sending compressed files to viewer gives an error

Technical Support
,
1

We have a Web API application that sends compressed PDF files using Brotli compression to the WebViewer on our web server.
For some reason I get this error message:
image

Here is the response header from our Web API app:
image

I also tried with application/pdf mime type, but still no luck.

Am I doing something wrong?!!

Also, even if the returned file has .br in the file name, I still see these warning:

image
image897Ă—97 7.99 KB

Maybe I should send the file as .br.pdf ?!
Somebody to clarify this.

Thank you.

2

Hello aleksandar.angelov,

How are you loading the files? Can you provide a code snippet?

Typically we see this when the endpoint from loading the file is not returning a PDF, and requires authentication or double-checking that the endpoint does resolve in a PDF.

The brotli compression is for the PDF workers, not for the PDF files so encoding the files is not necessary.

Best regards,
Tyler

3

Hi,

Here is part of the code that returns the file. This code returns a PDF and works with response compression:

var bytes = await System.IO.File.ReadAllBytesAsync(pdfFilePath);

int last_pos = pdfFilePath.LastIndexOf('/');
if (last_pos > 0) pdfFilePath = pdfFilePath[(last_pos+1)..];
else pdfFilePath = "file.pdf";

return File(bytes, "application/pdf", pdfFilePath, true);

pdfFilePath is the full path. I leave only the file name for the response. It looks like this: 1_123_456.pdf
The issue with this code is that I get the 2 warnings in the Web Browser.

Then I removed response compression and I tried this code, but it didn’t work:

var bytes = await System.IO.File.ReadAllBytesAsync(brFilePath);

int last_pos = brFilePath.LastIndexOf('/');
if (last_pos > 0) brFilePath = brFilePath[(last_pos+1)..];
else brFilePath = "file.br";

return File(bytes, "application/pdf", brFilePath, true);

brFilePath is the full path to the compressed file. I leave only the file name again. It looks like this: 1_123_456.br

Then I changed the file mime type, but it doesn’t work as well:

var bytes = await System.IO.File.ReadAllBytesAsync(brFilePath);

int last_pos = brFilePath.LastIndexOf('/');
if (last_pos > 0) brFilePath = brFilePath[(last_pos+1)..];
else brFilePath = "file.br";

return File(bytes, "application/x-br", brFilePath, true);

Thank you.

4

Hello aleksandar.angelov,

To load a file in WebViewer, it has to be an decompressed (brotli, gz, or whatever) PDF file, if you decompress the file then load it in the view.

How you handle compression and decompression of the file when in transit is up to your design.

Best regards,
Tyler

5

Hi,

How to get rid of these warning messages on the browser then?
I think, I’m missing some part of the logic here.

Thank you.

6

The warning messages you see in the console are due to the server hosting the files not supporting BR and GZ compression.

image
image897Ă—97 7.99 KB

See the guide in the warning message here: Content-encoding | Apryse Documentation for more information

Best regards,
Tyler

8

From the load document method I use a Spring Boot REST url with a redirect to a pre-signed url. I noticed that this endpoint is called twice by Apryse webviewer before loading the pdf. The first time it is called with Accept-Encoding “identity” and the second time with the Accept-Encoding “gzip, deflate, br, zstd“. The first time I do not redirect. The second time I redirect to a GET pre-signed url. This works!

1 Like
9

I added code to the Spring Boot filter that if the filename ends with br.wasm or br.mem I add “Content-Encoding” = “br” to the request header and the warnings have disappeared.

I also found out that sending the pre-signed url in a JSON response and handing that as a parameter to loadDocument shows that the first call is used to fetch the header of the pdf document and the second call is used to get the whole document. But this only worked in our application when a parameter “useDownloader” is set to false (the default of this parameter is true).

I also found out that when I run our application in incognito mode it also works when useDownloader is set to true. But I also found out that our application is using iFrames to embed the Webviewer because we use Jquery. We are using Webviewer version 10.6.0. When we switch to Webviewer version 11.x, the iFrames will not be there and the application should also work when useDownloader is set to true. Then we will also be able to use the multithreaded version of the Webviewer webassembly files which makes it possible to download the pdf in chunks of 1 MB.

We might try to upgrade to Webviewer 11.x, but we also are using Webviewer Video and Audio which are still using Webviewer 10.x underneath. If we upgrade to Webviewer 11.x, Webviewer Video and Audio are only working when iFrames are used (it will not work when web components are used).

1 Like