Set submission attachments to content-disposition: inline#1759
Draft
Set submission attachments to content-disposition: inline#1759
Conversation
Member
Maybe there's a way to frame that? Submission attachments are data collected for end user consumption, whereas things like form attachments are more like configuration for use in the context of an OpenRosa client. That said, the more I think about it, the more I'd be comfortable with us introducing a query parameter for this. Even leaving the default as |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of getodk/central#1659
This PR changes the content disposition to
inlineinstead ofattachmentfor Submission Attachment blobs only. Everything else (other blobs like form attachments, and computed files like csv exports) remains the same.The code change in
blobResponseapplies to both local blobs and S3-backed blobs. Central builds and passes along the response header with content type and disposition to S3 when fetching the remote URL.What has been done to verify that this works as intended?
Tests and trying it on submission attachments in Central.
Why is this the best possible solution? Were any other approaches considered?
We discussed adding a query parameter to specify attachments should be fetched
inlineorattachmentand talked about which way could be the default. This PR doesn't (yet) have that parameter, it just forces all submission attachments to be inline. But at least it doesn't change the content disposition everywhere, it only does it for submission attachments.Maybe it's weird for the submission attachments and other downloads to be be inconsistent.
We're not sure if there are use cases out there that depend on this being
attachmentrather thaninline.The "download attachment" page (mentioned in the issue) in central still works because there
atag is augmented:<a ... download>. This just uses the main attachment API but with frontend clicking an invisible link automatically.How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
Does this change require updates to the API documentation? If so, please update docs/api.yaml as part of this PR.
Yes, it probably does.
Before submitting this PR, please make sure you have:
make testand confirmed all checks still pass, or witnessed Github completing all checks with success