Repository navigation
WebApi.downloadURL() does not honour filename Content-Disposition response header #190
Description
I cannot get WebApi.downloadURL() to honour the filename returned in the response headers.
I don't know how to see what headers are returned by the jpro url .../resourcesdownload/http:/..., as once the browser opens it, it seems to be gone. So my guess is that the content disposition header is not proxied. (of course it could be some misuse/misconfiguration on my part, if so please advise)
Example:
Non Jpro endpoint http://host/file/1234 returns a file as octet stream.
It also returns a header Content-Disposition: attachment; filename=foo.txt
When accessing the above URL on a browser the file is saved as foo.txt, but when calling webApi.downloadURL("http://host/file/1234") the file downloaded by the browser is saved as 1234
I would expect the file to be saved as foo.txt and only use the last part of the URL if no Content-Disposition header with an filename is provided.
JPRO version: 2024.3.3
Chrome: Version 130.0.6723.92 (Official Build) (64-bit)
java:
openjdk version "21.0.5" 2024-10-15 LTS
OpenJDK Runtime Environment Temurin-21.0.5+11 (build 21.0.5+11-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.5+11 (build 21.0.5+11-LTS, mixed mode, sharing)
server OS:
Linux 3230f1148631 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
using jpro release
edits: grammar
Activity
FlorianKirmaier commentedon Nov 11, 2024
Small question regarding this:
Is the URL you want to download only accessible by the jpro-server or also the browser / jsclient?
The call "downloadURL" is a bit unspecific at the moment. It downloads something through the JPro server and makes it accessible to the client.
Maybe we should split it up in 2 methods: downloadServerURL() and downloadClientURL().
fulcrum-stelios-papadopoulos commentedon Nov 12, 2024
The URL points to a server running on a private network, so I was trying to use jpro-server as a tunnel.
I wanted to avoid exposing the private service. I worked around it by exposing the private service, and calling openURLAsTab(), so that the browser handles the download.
I would prefer to not have to expose that service when I approach a production release.