FileDownload: downloading .xhtml instead of PDF in Google Chrome (works in Mozilla Firefox)

[pvncoder]

Describe the bug

When attempting to download a PDF file and opening it in a new window using the contentDisposition="inline" attribute with p:fileDownload and ajax="false" on p:commandButton, the file is downloaded as .xhtml instead of a PDF in Google Chrome and Microsoft Edge. This issue does not occur in Mozilla Firefox.

Reproducer

FileDownloadReproducer.zip

1. Download the project.zip file;
2. Extract the contents of the project.zip file;
3. Deploy the project using a web application server (I'm using the Wildfly 27);
4. Open a web browser (Google Chrome or Microsoft Edge) and navigate to the following URL: "http://localhost:8080/filedownload/";
5. On the web page, click on the "Download" button;
6. Observe that the downloaded file has the incorrect extension (.xhtml) instead of being downloaded as a PDF.

Expected behavior

The PDF file should be downloaded correctly with the correct file extension (.pdf) in all supported browsers, including Google Chrome and Microsoft Edge.

PrimeFaces edition

Community

PrimeFaces version

12.0.0 Jakarta

Theme

AdminFaces

JSF implementation

Mojarra

JSF version

Jakarta Faces 4.0

Java version

20

Browser(s)

Google Chrome v114.0.5735.133; Brave Browser v1.52.126; Microsoft Edge v114.0.1823.51.

[melloware]

Works fine for me in Chrome and Edge:
pf-10251.zip

Run mvn clean jetty:run and navigate to http://localhost:8080/primefaces-test/

Same Mojarra 4.x and Jakarta EE10 version as Wildfly.

[pvncoder]

Works fine for me in Chrome and Edge: pf-10251.zip

Run mvn clean jetty:run and navigate to http://localhost:8080/primefaces-test/

Same Mojarra 4.x and Jakarta EE10 version as Wildfly.

Thank you for providing the project and instructions. I appreciate your assistance.

I downloaded and tested the provided project following your instructions. However, I am still experiencing the issue where the downloaded file is in the .xhtml format instead of being downloaded as a PDF. I have tested it on the latest versions of Google Chrome and Microsoft Edge.

[melloware]

Working fine for me in Windows 11 on latest Chrome and Edge. I have a feeling it is your machine?

[pvncoder]

Just to clarify, my computer is also running Windows 11. I have tested it on my brother's and father's computers as well, and the same issue occurred consistently using your provided project.

Additionally, I created a virtual machine running Lubuntu 23.04, and surprisingly, the problem persisted.

[pvncoder]

I noticed that the problem only occurs when I use the CTRL + S command or click on the download icon. However, if I use the CTRL + P command or click on the print icon and then choose "Save as PDF," it works correctly.

[melloware]

So maybe I am confused. You click the button and in my chrome is displays the PDF in the Chrome PDF Viewer no?

Are you saying when you then click the download button inside the chrome Viewer it tries to save it as XHTML and not a PDF?

This is NOT a PF issue it is just how Chrome\Edge works. See this Stack Overflow: https://stackoverflow.com/questions/53548182/can-i-set-the-filename-of-a-pdf-object-displayed-in-chrome#:~:text=In%20Chrome%2C%20the%20filename%20is,page%20using%20the%20object%20element.

I suggest if you need more control over the download name you want to use PrimeFaces Extensions Document Viewer component

https://www.primefaces.org/showcase-ext/views/documentViewer.jsf

[pvncoder]

Thank you for the suggestion to use the "PrimeFaces Extensions Document Viewer Component." I appreciate your recommendation and will definitely explore it further as it might be beneficial for another screen in my application.

I understand that Google Chrome interprets the URI to initiate the file download. However, the reason for opening this issue is that in older versions of PrimeFaces (specifically version 6.2), with Wildfly 20 and using the Javax namespaces instead of Jakarta, the file download process works as expected when using the CTRL + S command or clicking on the download icon (resulting in a proper .pdf file download).

I wanted to highlight this difference in behavior between the older version of PrimeFaces and the current one, where the file is mistakenly downloaded as an XHTML file instead of a PDF file. This led me to believe that there might be some compatibility or configuration issue specific to the latest PrimeFaces version.

Here is a Reproducer file showcasing the proper functioning of the PDF download feature (please note that you will need an application server that supports the javax namespaces instead of Jakarta, as the older versions of PrimeFaces utilize the javax namespaces):

FileDownloadReproducerPrimefaces6.2.zip

See how the PDF was successfully downloaded by using the CTRL + S command:

[melloware]

Some interesting observations. The request / response looks practically identical.

PF 6.2 on Jetty 9:

PF 12.0 on Jetty 11:

Notice the URL test.xhtml is identical as well as the Content-Disposition etc.

[melloware]

OK @Pedr0Vitt19 got to the bottom of it. This ticket is what is causing the issue: #6359

That was introduced in 10.0.0 to add NO Cache Control for GDPR. Firefox seems to like it but Chrome and Edge see that its not cached and no longer have the real file so they must fall back to the URL for the file name. Not sure if its an issue with Chrome or with Firefox not respecting the HTTP spec.

@tandraschko from reading the ticket the idea was since these files are always dynamic they should never be cached. Not sure if this is worth fixing for this corner case?

[tandraschko]

caching dynamic generates files does not make any sense TBH

[pvncoder]

I believe it would be beneficial to address this issue to ensure consistent behavior across different browsers. One possible solution could be that we add a property to the p:fileDownload component that allows us to specify whether dynamically generated files should be cached or not. By default, the "NO Cache Control" behavior could be retained, but we would have the flexibility to enable caching if desired, depending on our specific project requirements.

I would like to suggest considering this enhancement as it would provide more control and flexibility to developers while still maintaining compliance with GDPR regulations.

[melloware]

I submitted a PR for review.

[pvncoder]

Ok thank you for this.

[Bukama]

Just saw this ticket. This is EXACTLY the same problem I mentioned in Discord some months ago.
We decided to change the download to enforce downloading the file instead of showing the PDF (but we could do this, because our requirements do not force us to show the PDF)

[mstichweh]

The problem seems to be only the "no-store" option of the "cache-control" header. So the default for the p:fileDownload component should be just without "no-store":

externalContext.setResponseHeader("Cache-Control", "no-cache, must-revalidate");
externalContext.setResponseHeader("Pragma", "no-cache");
externalContext.setResponseHeader("Expires", "0");

Then it is still possible to download dynamical generated files without caching. For very secure documents the "no-store" option could be explicitly switched on by an additional p:fileDownload attribute. Or the "Cache-Control" header becomes configurable, e.g. via the StreamedContent to override the default.

[melloware]

OK updated my PR.

[melloware]

Backported to 13.0.6

[JonatanRoo]

Hi,
We are on PF10 right now and are having problem with this bug. We would need to solve it asap and an upgrade to 13 could take some time. Is there something we can do to fix this?

I looked at ca23137
and blocked/modified the headers with a Filter and a HttpServletResponseWrapper but it's still not opening as an PDF in Chrome.

Any advice appreciated.

[melloware]

If you are on PF10 you would porbbaly have to grab a Tag of PF10 here in GitHub and rebuild from Source with the hacked fixed for nostore

[JonatanRoo]

@melloware ok thanks. Any ideas why just modifying the headers does not work? I tripple checked that they really are the same as in the fix. no-store is gone but still not working.

[melloware]

hmmm nope? that looks right.

[JonatanRoo]

Ok thanks anyway for your quick replies 👍