On 2018-07-19 18:16, Matt Ryan wrote:
On July 18, 2018 at 4:16:28 AM, Julian Reschke (julian.resc...@gmx.de
<mailto:julian.resc...@gmx.de>) wrote:
On 2018-07-18 09:42, Marcel Reutegger wrote:
>> I would say that these are not *necessarily* HTTP-specific, and thus
>> we should try to define them in a generic way.
>
> I agree when we look at file name and content type, these are also
> present in JCR when you have a nt:file/nt:resource node structure, but
> we probably also want to add a content disposition type to the download
> options. How would you define this in a generic way?
> ...
Adding the disposition type here is a new concept. Why is it needed now
and not before?
Well, RFC-6266 defines that the disposition type is part of the
Content-Disposition header (as you know Julian, since you wrote the RFC)
- a required part of that header, as I understand the RFC. I assumed
that a client would need a way to specify whether they want “inline” or
“attachment”.
Well, yes, it needs to be set in the header, but that doesn't mean that
we need to choose. In *general*, "inline" should be ok.
For example, using “attachment” as a default disposition type seems to
make sense to me based on section 4.2 of that RFC (interpreting that
section as it applies to this case). If the user wanted to generate a
web page with binaries that are rendered inline, they’d need a way to do so.
If we set it to "attachment" images will not be displayed. Is that what
we want? I'm still confused about how we can make that distinction when
we create the binary...
Do you have a different view?
AFAIU, some applications on top of the JCR API add the "atttachment"
disposition type in order to prevent browsers to run user-provided
HTML/JS. But those do that in a servlet filter, right? We'd have to find
out how to address this use case with the new API...
Best regards, Julian
IIUC doing this in a servlet filter wouldn’t work in this case because
the URI has to be signed for the way it is requested (no modifying the
URI in code after it is obtained) and the request for the binary won’t
go through the JVM (no filtering available).
We could control it if we did another redirect the the cloud storage,
instead of using the "raw" URIs directly. But of course that would be
another roundtrip.
So yes, keeping control over the disposition type is tricky.
Best regards, Julian
