[jira] [Comment Edited] (OAK-7637) [DirectBinaryAccess][DISCUSS] How to set response headers for direct download URIs?

["Julian Reschke (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OAK-7637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16546010#comment-16546010 ] 

Julian Reschke edited comment on OAK-7637 at 7/17/18 5:16 AM:
--------------------------------------------------------------

The ability to modify Content-Type as request parameter sounds like a security issue waiting to happen.

If the stores support setting the Content-Type upon creation, why not use it?

Also, the code looks as if Content-Disposition just gets the filename. This is not how Content-Disposition works. FWIW, there may be other problems down the road if other parts of the server set C-D to "attachment" for security reasons.


was (Author: reschke):
The ability to modify Content-Type as request parameter sounds like a security issue waiting to happen.

If the stores support setting the Content-Type upon creation, why not use it?

> [DirectBinaryAccess][DISCUSS] How to set response headers for direct download URIs?
> -----------------------------------------------------------------------------------
>
>                 Key: OAK-7637
>                 URL: https://issues.apache.org/jira/browse/OAK-7637
>             Project: Jackrabbit Oak
>          Issue Type: Technical task
>          Components: blob-cloud, blob-cloud-azure
>            Reporter: Matt Ryan
>            Assignee: Matt Ryan
>            Priority: Major
>
> 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.
> h3. 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.
> h3. 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.
> h3. 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.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)