Enhancement: hyper storage accepts binary data in addition to form data

[TillaTheHun0]

Use Case

As a developer using a hyper Storage service
I would like the ability to post binary data to my hyper Storage Service
So that I can forego creating FormData on the server, and even stream request bodies directly into hyper Storage

Background

FormData is usually accepted for file uploads because a web form is most commonly the mechanism used for sending files to an app's backend. But hyper is sort of "the backend to the backend". In other words, hyper won't be directly connected into a web form UI. So it makes sense for HTTP based hyper apps storage api to be able to receive binary data. The mechanism for how that file's binary data is sent to hyper, whether via a web form processed by a hyper client's backend, or from a curl, or something else is application level concern. It just feels a bit unergonomic for clients to have to create FormData to put objects into hyper.

On file uploads we buffer the body (multipart/form-data) into a temp file, then pass a Deno.Reader into the Core. So the current flow is:

1. The hyper driving app buffers request body into a tmp file
2. The hyper driving app creates a Reader for that content and passes it to core
3. Core passes to the adapter which is then implementation specific

However the Request body is itself a Deno.Reader, or in the case of the Express adapter, an AsyncIterable which can be converted into a Deno.Reader. So instead we could pass the body directly to Core as a Deno.Reader, bypassing 1 and 2 entirely.

Proposal

Instead of a breaking change, I think i've figured out a way to support both binary data and multipart/form-data, by using a combination of Content-Type and Accept headers on the request.

• If the Content-Type is multipart/form-data then the body is handled as FormData (current behavior)
• If the Accept header is application/json or the the useSignedUrl query parameter is provided or if there is no Content-Type header at all, then the signed url flow is used (current behavior)
• Otherwise the body is assumed to be binary data (new behavior)

In other words, providing a Content-Type of application/octet-stream, along with a url path ie. /foo/bar.png would trigger the binary data flow. This would also handle other headers ie. image/png as binary data. Pretty cool!