GET URL opens directly in browser, download button missing

[coolji]

I'm encountering an issue with the Openfire HTTP File Upload plugin(1.3.0). When accessing a file through the GET URL generated by the plugin, the browser opens the file directly instead of displaying a download button.

Here are the details of the issue:

Steps to reproduce:

Upload a file using the plugin. Access the generated GET URL for the uploaded file. Expected behavior: The browser should display a download button, allowing the user to save the file. Actual behavior: The browser opens the file directly, often displaying the content inline.

I checked but not able to find any configuration where I can define the content type or content-disposition header to make it downloadable.

I would appreciate it if you could investigate this issue and suggest potential solutions or workarounds. If there are configuration options to control download behavior, please provide guidance on how to access them.

[guusdk]

HTTP File Upload plugin's URLs are not really intended to be used directly in a browser. The plugin certainly does not intent to present any kind of UI interface for end-users. This plugin provides infrastructure, not a end-user facing feature.

Instead, it is expected that a client that gets sent the download URL provides appropriate UI elements to present a reference to the data that is being exchanged.

The plugin does currently not allow the uploader to explicitly define the content type of the data (an issue for this feature request exists here). Instead, the plugin will attempt to determine the content type based on the file data and metadata.

[birla94]

thanks @guusdk for the prompt reply. we are direclty sharing the GET URL to access the media file mp3 but that third party module is rejecting file because the file content-type is generic applicate/octet-stream and it only support audio/mpeg. and because of it we are not able to exchange mp3 files do you have any workaround or we need to create some wrapper to provide end to end features?

[guusdk]

Try using a filename value that ends with 'mp3'. Otherwise, the most prudent way to achieve this is by fixing the feature request that I linked to above.

[birla94]

when i checked the fileRepo path. files are saved as alphaNumeric number without file extension. and to access the file we are using GET URL for eg. https:///httpfileupload/oRXUINag5U4FXgKIB1-V-lypNcE/test.mp3

but still the content-type is not resolved.

[guusdk]

Then I'm not sure if there's another way to get this to work other than implementing https://github.com/guusdk/httpfileuploadcomponent/issues/25