Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WebApi.downloadURL() does not honour filename Content-Disposition response header #190

Open
fulcrum-stelios-papadopoulos opened this issue Nov 7, 2024 · 2 comments

Comments

@fulcrum-stelios-papadopoulos
Copy link

fulcrum-stelios-papadopoulos commented Nov 7, 2024

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

@FlorianKirmaier
Copy link
Contributor

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants