Attachments API use filename from Content-Disposition before url

[tylerjmchugh]

Currently the attachments putResourceFromURL API uses the last node from the URL (excluding query parameters) to get the filename. This becomes an issue when providing URL's that do not contain the filename in the last node. Instead the content disposition header should have higher priority over the url for retrieving the filename.

For example when providing a URL for a file that is uploaded to a cloud provider like OneDrive the download URL looks like .../.../download.aspx?.... This means when putResourceFromUrl is called the extracted filename is always download.aspx rather than the actual file download's name. If content disposition is used instead the actual filename can be extracted from the header.

Additionally there are some issues with the "consumes" and "produces" spring docs for putResource and putResourceFromURL leading to an incorrect OpenAPI spec which causes the APIs to fail or return invalid responses. This also causes the swagger page to be incorrect and causes issues for codegen as the generated methods for putResource do not correctly provide the file as multipart/form-data.

This should show that only multipart is accepted:

Issues with response codes because JSON is not defined as the return type (This call was successful):

This PR aims to fix these issues by first attempting to get the file name from the Content-Disposition header before falling back to the URL for the filename and by updating the spring docs.

Checklist

• I have read the contribution guidelines
• Pull request provided for main branch, backports managed with label
• Good housekeeping of code, cleaning up comments, tests, and documentation
• Clean commit history broken into understandable chucks, avoiding big commits with hundreds of files, cautious of reformatting and whitespace changes
• Clean commit messages, longer verbose messages are encouraged
• API Changes are identified in commit messages
• Testing provided for features or enhancements using automatic tests
• User documentation provided for new features or enhancements in manual
• Build documentation provided for development instructions in README.md files
• Library management using pom.xml dependency management. Update build documentation with intended library use and library tutorials or documentation

[josegar74]

I have tested with some URL's and files from Google Drive, but Content-disposition is not set. I don't have access to OneDrive, but if you have tested, looks ok.

See the comment in the code.

[josegar74]

If an exception occurs, should not be better to return null, so it falls back to getFilenameFromUrl?

[tylerjmchugh]

Good point, fixed in latest commit

[tylerjmchugh]

I have tested with some URL's and files from Google Drive, but Content-disposition is not set. I don't have access to OneDrive, but if you have tested, looks ok.

See the comment in the code.

I am having trouble finding a sample resource that uses Content-disposition other than on my own OneDrive but yes it is tested and works when the content disposition header is present. Also I fixed the issue you identified.