jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Ryan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-7637) [DirectBinaryAccess][DISCUSS] How to set response headers for direct download URIs?
Date Tue, 17 Jul 2018 23:23:00 GMT

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

Matt Ryan commented on OAK-7637:
--------------------------------

I had a discussion today with Marcel and another with [~alexander.klimetschek] on this. 
Definitely there are changes needed to the PR - as I said it was just a prototype.  Good
to have the feedback so we can evolve it to something useful.

Based on those conversations I'm taking the following steps:
 * I'm removing the {{getProperties()}} method which will involve the use of a complementary
class at different layers down the Oak stack, similar to {{BinaryDownload}} / {{BlobUpload}}
/ {{DataRecordUpload}}.
 * I'll change {{BinaryDownload.getURI()}} so it always requires an options object.  I'll
add a static field on the options class so it is easy to obtain a default object.
 * I will add the ability to specify the content type encoding as well as the content type.
 * I'll document that valid content types are those defined as valid for jcr:mimeType, and
that valid content type encodings are those defined as valid for jcr:encoding, though the
parameters will just be string parameters with no validation of the value passed in.
 * I will add the ability to specify whether the content disposition should be "inline" or
"attachment" as well as the filename.  (After discussion Alex and I didn't think we need
to support "filename*" for the content disposition; [~reschke] do you agree?)
 * For cache control, I will set {{max-age}} to the same value as the one used in the TTL
for the signed URI; I will also set "private" and "immutable" on the cache control header.
 ** The {{Expires}} header for the response can be set in the S3 API for the signing request,
but not for Azure, so I won't plan to set the {{Expires}} header at all.
 ** Regarding "Immutable" - I realize browser support for immutable isn't consistent, but
I don't know that we care so much.  We know our binaries are immutable so I don't see the
harm in setting this in the header.

I'll add an updated PR when I have one.

> [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)

Mime
View raw message