DownloadHandler - nonASCII filename

sladjan.vasic · August 8, 2025, 7:13am

New download handler does not handle filenames as expected. If we use non-ASCII letters for filenames, it offers the word “download” as the filename. That is at least the case in version 24.8.0.

Is this fixed in later minor versions?

When setting Content-Disposition in the response header, Vaadin sets only filename (the fallback option) and not filename* (with an asterisk) for the encoded UTF-8 filename.

Also, if we use an inline link in DownloadHandler for a dynamically generated PDF file, the filename isn’t shown in the browser viewer, as it was in previous versions of Anchor.

Is this issue addressed anywhere?

For now, I must use the old way of writing data to the event’s output stream directly and handling Content-Disposition headers myself, which makes DownloadHandler unusable for most cases where we want to have a non-ASCII filename.

knoobie · August 8, 2025, 7:21am

It’s always recommend to use the latest patch release - not staying on the first minor release and hope for the best.

About your problem: nope, it’s not addressed and there is no issue about it. I remember mentioned it in the design phase of the downloader

Matti · August 8, 2025, 7:41am

I reported this to Flow team lead earlier in the summer, but I guess he is still trying to empty his comms after vacay. Here is how it is handled in Viritin (which was kind of the inspiration for the changes, but the implementation was not copied as such):

github.com

viritin/flow-viritin/blob/bc2ad43f85e71119c8668960ee19e1e871992915/src/main/java/org/vaadin/firitin/components/DynamicFileDownloader.java#L263


      
          if (hasStartedListeners) {
              ui.access(() -> {
                  DynamicFileDownloader.this.getEventBus().fireEvent(new DownloadStartedEvent(DynamicFileDownloader.this, false));
              });
          }
          response.setStatus(200);
          String filename = getFileName(session, request);
          if (filename == null) {
              filename = fileNameGenerator.getFileName(request);
          }
          response.setHeader("Content-Disposition", (newWindow ? "" : "attachment;") + "filename*=" + encodeRfc5987Filename(filename));
          response.setHeader("Content-Type", contentTypeGenerator.getContentType());
          // Set a cookie to indicate that the file has been downloaded, browser registers after the
          // download is complete, and we can then hit the server (from the client) to check for possible
          // errors and UI modifications
          Cookie marker = new Cookie("filedownloadmarker-" + id, "filewritten");
          marker.setPath("/");
          // Client side ought to clear this (if attached), but set a reasonable max age anyways...
          marker.setMaxAge(60 * 60);
          response.addCookie(marker);
          try {

Reguler “filename” field, without the , is obsolete as all browsers that Vaadin supports supports the "filename" version.

If you can’t drop in Viritin dependency, you can copy the helper function and override the content disposition header settings to make this work with the new API.

lipisak · August 8, 2025, 12:56pm

Hi Matti,
I have a file called: Re nedoručené noviny dne 4.7.2025 - zák. č. 123812382 Ing. Peter Smith.msg

I know the file name is terrible but our customers required these kinds of name. Is it possible that this bug is affecting me too? Whenever I try to download the file with this name I got some kind of uuid as downloaded filename.
If I change the name to for example test.vnd everything is OK. If I remove all the accents (č,é,á,…) it works too.
Is there a raised issue in github for this? It would be nice to link it here.

Thank you

Best regards
JS

Matti · August 8, 2025, 3:01pm

I think it is the same. I don’t remember seeing a proper GH issue, so please go ahead, I’ll bring in my thumb up to it

lipisak · August 10, 2025, 7:01pm

Hi Matti,
this is the issue: DownloadHandler incorrectly handles files with non-ASCII characters in filename · Issue #22007 · vaadin/flow · GitHub

Best regards
JS

sladjan.vasic · August 11, 2025, 11:27am

I cannot get the desired result in any case (neither with DownloadHandler nor with DynamicFileDownloader - both updated to latest versions).

The goal is to get a link that opens a dynamically generated PDF in a new tab. In the new tab, the title must be present in the viewer’s header, as was the case in previous versions. In versions 24+, this title is missing, which is also apparent when we click the “Download” button in the viewer, where the title is automatically converted to filename as “download.pdf” regardless of the filename we set.

I did get non-ASCII filename properly when using DynamicFileDownloader though in case of opening “Save as” dialog, but I can’t get desired result with calling method .inNewWindow()

Matti · August 12, 2025, 7:55am

Would you share some screenshots and/or details about what browsers and OSs are in use? There are definitely some environment related issues. This mayb be hard to get right, but I’m eager to try.

Matti · August 13, 2025, 6:24am

While waiting for more details I did a quit testing with pdf’s on Mac. Based on it, only Firefox seems to be properly behaving. With the new API in Vaadin 24.8, this might be possible to be worked around, in case the file name is given upfront (so that it would be present in the URL).

github.com

viritin/flow-viritin/blob/v24/src/test/java/org/vaadin/firitin/DynamicFileDownloadingDemo.java#L227-L231


      
          var inlinePdf = new DynamicFileDownloader("Download inline PDF", "inlöäöäineشريط.pdf",
                  out -> Files.copy(Path.of("src/test/resources/pdf.pdf"), out))
                  .withContentTypeGenerator(() -> "application/pdf")
                  .inNewWindow();
          add(inlinePdf);

@sladjan.vasic Do you happen to use Adobe PDF plugin? It might also behave differently, didn’t check.

Matti · August 13, 2025, 6:37am

Sorry for confusion, it actually seems to be working fine with Mac on all browsers (had some confusion on my side). So waiting for more details.

Below is how this can be accomplished with 24.8 API, with bit of low level hacking with http headers:

lipisak · August 15, 2025, 3:37pm

I saw there is pull request on the way. it looks promising.

sladjan.vasic · August 18, 2025, 9:09am

I used this approach with Anchor and it works as expected. Thank you Matti.

I am using Chrome on Ubuntu without Adobe PDF plugin.