On July 18, 2018 at 4:16:28 AM, Julian Reschke ([email protected]) 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”. 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. 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). -MR
