Current Behavior
According to the relevant specifications (see sources below), the default filename parameter of the Content-Disposition header must conform to ISO‑8859‑1, which does not support emojis.
During our migration to Tomcat on Kubernetes, we encountered an inconsistency in behavior when a filename contains an emoji. WebSphere throws an exception in this scenario (which is also undesirable), whereas Tomcat silently drops the entire Content-Disposition header.
The specifications also define an alternative filename* parameter, which allows the filename to be encoded in UTF‑8. By applying the configuration changes described below, the response behaves as expected: the Content-Disposition header is preserved and modern browsers correctly select the UTF‑8 filename for the download.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Disposition
https://datatracker.ietf.org/doc/html/rfc5987#section-3.2
Expected Behavior
By setting the Content-Disposition header, the server explicitly instructs the browser to download the response payload and to use the provided filename for the downloaded file.
The framework should assist Frank developers in complying with the Content-Disposition specifications by offering a generic and consistent way to indicate that a response is intended for download. This should be supported by the API listener and, where applicable, by other HTTP‑based listeners as well.
Environment Information
7.9.7-ee on k8s, tomcat 9, java 11
Steps To Reproduce
No response
Configuration
Input
No response
What database are you using?
No response
What browsers are you seeing the problem on?
No response
Relevant Log Output
Anything else?
No response
Current Behavior
According to the relevant specifications (see sources below), the default filename parameter of the Content-Disposition header must conform to ISO‑8859‑1, which does not support emojis.
During our migration to Tomcat on Kubernetes, we encountered an inconsistency in behavior when a filename contains an emoji. WebSphere throws an exception in this scenario (which is also undesirable), whereas Tomcat silently drops the entire Content-Disposition header.
The specifications also define an alternative filename* parameter, which allows the filename to be encoded in UTF‑8. By applying the configuration changes described below, the response behaves as expected: the Content-Disposition header is preserved and modern browsers correctly select the UTF‑8 filename for the download.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Disposition
https://datatracker.ietf.org/doc/html/rfc5987#section-3.2
Expected Behavior
By setting the Content-Disposition header, the server explicitly instructs the browser to download the response payload and to use the provided filename for the downloaded file.
The framework should assist Frank developers in complying with the Content-Disposition specifications by offering a generic and consistent way to indicate that a response is intended for download. This should be supported by the API listener and, where applicable, by other HTTP‑based listeners as well.
Environment Information
7.9.7-ee on k8s, tomcat 9, java 11
Steps To Reproduce
No response
Configuration
Input
No response
What database are you using?
No response
What browsers are you seeing the problem on?
No response
Relevant Log Output
Anything else?
No response