Stacks.js: Option to pass Content-Type to putFile API

[muneebm]

The current implementation sets Content-Type header to either 'text/plain' or 'application/octet-stream' based on the type of the input parameter content.
For example, if you want to store a publicly accessible html file, the current implementation stores it with 'text/plain' header. And if you access the public read URL from a web browser, the HTML will be interpreted as plain text.
So it would be helpful to have another option in options parameter to pass the Content-Type header.

[hstove]

This is a great suggestion. @jcnelson would Gaia be able to utilize this when responding to reads, and return the correct Content-Type?

[jcnelson]

I'm confused. The content-type returned by the Gaia hub should be irrespective of the value of content. The contentType parameter in uploadToGaiaHub simply controls the Content-Type header value in the POST request that stores the data. It should have no bearing on the Content-Type header returned by the Gaia hub on getFile(). In fact, it is impossible for Gaia to control the Content-Type header on the read path, since Gaia isn't on the read path in the first place.

[muneebm]

Sorry for the confusion, but the issue is when you try to access the publicURL returned by the uploadToGaiaHub from the browser, in case of an HTML file.
For example, consider these two public URLs:

1. Uploaded with current putFile implemation ('text/plain' for string content), displays HTML as plain text: index1.html
2. Same HTML uploaded with 'text/html' header, displays HTML: index2.html

The contentType parameter in uploadToGaiaHub simply controls the Content-Type header value in the POST request that stores the data

The change I suggested, I think, will give the user an option to control this Content-Type header.

[jcnelson]

Ah, I see. It appears that the driver itself has to store the content type given on the POST request, and the back-end storage provider is expected to serve it in the future. Turns out, they all do this except for the disk driver already. So, your PR should work after all :+1: . We'll need to fix the disk driver to emulate this behavior.

[larrysalibra]

Thanks @muneebm for adding this functionality!! It will be in the next release.