(storage) getUrl should support contentDisposition (again; used to)

[mitchh]

Is this related to a new or existing framework?

Angular, React, Vue, Next.js

Is this related to a new or existing API?

Storage

Is this related to another service?

No response

Describe the feature you'd like to request

Storage.get used to allow specification of Content-Disposition in the returned URL; in v6 it is no longer possible, with the rationale Content options (contentDisposition, contentLanguage, contentEncoding, and contentType) are no longer supported in the get API as these values are already provided in the uploaded file. While this does apply to most of the other Content-* headers, Content-disposition is not about the content of the file itself, and has other uses. Specifically, consider this comment from the Android SDK:

 * For example, a client could dynamically change the apparent
 * Content-Disposition header of a single object, so that it appears to have a
 * different file name for different callers. One client could be configured
 * return the object with
 *
 * <pre>
 * Content-Disposition: attachment; filename=FileName1.exe
 * </pre>
 *
 * while another could return that same object with headers
 *
 * <pre>
 * Content-Disposition: attachment; filename=FileName2.pdf
 * </pre>
 * ```
 

### Describe the solution you'd like

Add `contentDisposition` (or maybe better yet, a `headers` object that can include `content-disposition`) to `options` in `getUrl`

### Describe alternatives you've considered

Don't have a good alternative ATM

### Additional context

_No response_

### Is this something that you'd be interested in working on?

- [X] 👋 I may be able to implement this feature request
- [ ] ⚠️ This feature might incur a breaking change

[cwomack]

Hello, @mitchh 👋. It indeed is a change from v5 behavior after upgrading to v6 that the contentDisposition (as you noted in the docs here. I'll review this with our team internally, but could you give some further context and use case for this to ensure we understand a broader range of how the contentDisposition option will be used?

[mitchh]

I have files stored (using Amplify, FWIW) by a previous version of our app with various `Content-Disposition` header metadata. The most interesting ones are PDFs. At times I want them to display inline in the browser, and I also want to provide download URLs. It seems wasteful to have to manage multiple copies with different metadata. That is an S3 design decision rather than an Amplify issue, but in v5, and in the S3 API underlying it, the ability to override them in a presigned URL provides a solution. To be honest, I find the whole notion of storing headers (specifically this one directing the handling rather than the content) with files a little odd, though I can see why it's handy much of the time. That said, being able to override them provides flexibility, and I would rather stay in Amplify than have to go craft my own URLs.

…

On Wed, May 1, 2024 at 1:21 PM Chris Womack ***@***.***> wrote: Hello, @mitchh <https://github.com/mitchh> 👋. It indeed is a change from v5 behavior after upgrading to v6 that the contentDisposition (as you noted in the docs here <https://docs.amplify.aws/react/build-a-backend/storage/storage-v5-to-v6-migration-guide/#storageget:~:text=mentioned%20above%3A-,Content%20options,-()>. I'll review this with our team internally, but could you give some further context and use case for this to ensure we understand a broader range of how the contentDisposition option will be used? — Reply to this email directly, view it on GitHub <#13326 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEJUI5IURFBPRY5WUHXUN3ZAFFC5AVCNFSM6AAAAABHCK54ASVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBZGA3TCOBXGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>