Spring boot actuator offers a simple HTTP api to write web endpoints. It is intended to be simple. I have a usecase where I use embedded async-profiler and allow profiling of my spring boot application.

One of the file format I support is JFR and I want to be able to allow user to download the file from actuators. In current API setup download of file is possible however naming the downloaded file is not.

This is to support such usecase.

Comment From: wilkinsona

From what you have described, the heap dump endpoint sounds similar to your endpoint in that it produces binary data that is typically written to a file. In the Actuator API documentation we document the use of curl's -O to write the heap dump to disk. This results in a file named heapdump (derived from the URL) which isn't quite what you want.

With curl, you can use -o, --output <file> to specify the name of the file to which the response body is written. Even if the server was able to suggest a default filename, I think it's likely that a user may want to customise it to meet their own needs and is likely to use -o or an equivalent option with a different client to do so. From what I know thus far, it feels like your use case may be solved by some documentation.

Comment From: JigarJoshi

Yes we can make the client output to different file while using such clients. However in my experience I have seen many developers using browser to hit certain actuator endpoints.

While we can't attach response header Content-Disposition: attachment; filename="${NAME}" it defaults to the last part of uri (for example heapdump in case of /heapdump). Users will then have to rename file to add certain extension for the toolings (For example JMC).

This isn't a must have feature but as actuator grows I think it will be nice to add it in. I am happy to take your suggestion and introduce/reuse proper model for HttpHeader instead of MultiValuedMap.

Please let me know what do you think

Comment From: philwebb

We discussed this today as a team and decided that unfortunately we don't want to surface HTTP headers in the WebEndpointResponse class. If your code is just targeting one specific technology, you might want to look at @RestControllerEndpoint (and equivalents) which surfaces the existing MVC API, including support for HTTP headers.