[DirectBinaryAccess][DISCUSS] How to set response headers for direct download URIs?

There are at least three headers that need to be set in responses to direct GET URIs:

• Content-Type
• Content-Disposition
• Cache-Control

In order for the URIs to behave as expected when directly reading a binary, these headers should be set.

Content-Type

Binary data is stored in an Oak repository as raw bytes only, with no associated content type.  When a client obtains a download URI and issues a request to that URI, the resulting response should have the Content-Type header set so that the binary data will be interpreted properly by the client.

Content-Disposition

Binary data is stored in an Oak repository using a system-generated identifier for the blob, which is not a user-friendly name for the content being represented.  When a client obtains a download URI and issues a request to that URI, the resulting response should have the Content-Disposition header set to a user-friendly name for that binary.  For example, a PDF document stored in the repository as "TeamGoals.pdf" would have a completely different blob name, and the generated URI to read that PDF directly from storage would also have that unhelpful name.  If the Content-Disposition header is set, then an end user trying to save the PDF from a web page link would save it using the name returned in the Content-Disposition header rather than the blob name.

Cache-Control

Since binary data in an Oak repository is essentially not changed after it is created, it is cacheable, so the Cache-Control header should be set to allow the binary to be cached.