Skip to content

Comments

Set submission attachments to content-disposition: inline#1759

Draft
ktuite wants to merge 1 commit intomasterfrom
ktuite/content-disposition-inline
Draft

Set submission attachments to content-disposition: inline#1759
ktuite wants to merge 1 commit intomasterfrom
ktuite/content-disposition-inline

Conversation

@ktuite
Copy link
Member

@ktuite ktuite commented Feb 20, 2026

Part of getodk/central#1659

This PR changes the content disposition to inline instead of attachment for Submission Attachment blobs only. Everything else (other blobs like form attachments, and computed files like csv exports) remains the same.

The code change in blobResponse applies 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 inline or attachment and 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 attachment rather than inline.

The "download attachment" page (mentioned in the issue) in central still works because there a tag 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:

  • run make test and confirmed all checks still pass, or witnessed Github completing all checks with success
  • verified that any code from external sources are properly credited in comments or that everything is internally sourced

@matthew-white
Copy link
Member

Maybe it's weird for the submission attachments and other downloads to be be inconsistent.

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 attachment. It's easy enough for users to specify a query parameter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants