Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement Direct Upload of Binary Content at the Binary Endpoint #2126

Open
Tracked by #2009
allentiak opened this issue Oct 18, 2024 · 0 comments
Open
Tracked by #2009

Implement Direct Upload of Binary Content at the Binary Endpoint #2126

allentiak opened this issue Oct 18, 2024 · 0 comments
Assignees

Comments

@allentiak
Copy link
Member

allentiak commented Oct 18, 2024

Specification:

  • When binary data is written to the server (create/update - POST or PUT), the data is accepted as is and treated as the content of a Binary, including when the content type is "application/fhir+xml" or "application/fhir+json", except for the special case where the content is actually a Binary resource.

Scaffolding:

  • Check the blaze.middleware.fhir.resource middleware. There, we also need a wrap-binary-resource function that has to allow non-fhir content-types and will create a Binary resource on the fly using the body as :data (base64 encoded, of course) and adding the content-type as :contentType.

  • At the end, both moddleware functions, the already existing wrap-resource and the new wrap-binary-resource have to emit a FHIR resource to the next middleware/handler.

  • We will also need integration tests for this feature. In order to implement them, we can use the openssl command like in .github/scripts/generate-large-binary-resource.sh to generate such a large 8 MiB random content for the integration test. We should be able to upload and download that content and it should be equal afterwards.

Part of #2009.

@allentiak allentiak self-assigned this Dec 10, 2024
allentiak added a commit that referenced this issue Dec 13, 2024
Whereas the names `e` and `ex` are quite similar, they can still
generate some confusion.
allentiak added a commit that referenced this issue Dec 14, 2024
* `generate-error-payload` (and not just `error`) is what the function
actually does
* Whereas the names `e` and `ex` are quite similar, they can still
generate some confusion.
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

No branches or pull requests

1 participant