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 Mon, 16 Jul 2018 22:02:00 GMT

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

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

I'm unsure what value to use for {{Cache-Control}}.  There's an argument to set it to a high
value since it won't be modified after creation.  However, presumably the TTLs on the GET
URIs will be short anyway, so does it really matter whether the max age is set to a year if
we assume the TTL will be extremely short anyway?  Also I wonder how this should be set keeping
in mind that while objects can't be modified once created, they can be deleted.  Also, are
there other {{Cache-Control}} settings we should have besides just {{max-age}}?  Finally,
do we need to set the {{Expires}} header also?  I realize the spec tells clients to ignore
it if {{Cache-Control}} is also there, but is it reasonable to assume that all clients and
proxies understand {{Cache-Control}} or are there still enough that only understand {{Expires}}?

Looking for some opinions here ([~reschke] I'm thinking of you in particular but any opinions
welcome)

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