Re: Supporting direct binary access - PR submitted

[Julian Reschke]

On 2018-07-23 09:30, Marcel Reutegger wrote:

Hi,

On 19.07.18 19:28, Julian Reschke wrote:
If we set it to "attachment" images will not be displayed. Is that 
what we want?


The idea is, that it is up to the application (on the server) to decide
on a case by case basis whether 'attachment' or 'inline' is suitable.


OK, question is where that decision logic would live...

Also, the default definitively would need to be "inline".


I'm still confused about how we can make that distinction when we
create the binary...


This is not when the binary is created, but when a URI is created for
requesting the binary.


Ok.

Best regards, Julian

Re: Supporting direct binary access - PR submitted

[Marcel Reutegger]

Hi,

On 19.07.18 19:28, Julian Reschke wrote:
If we set it to "attachment" images will not be displayed. Is that 
what we want?


The idea is, that it is up to the application (on the server) to decide
on a case by case basis whether 'attachment' or 'inline' is suitable.


I'm still confused about how we can make that distinction when we
create the binary...


This is not when the binary is created, but when a URI is created for
requesting the binary.

Regards
 Marcel

Re: Supporting direct binary access - PR submitted

[Julian Reschke]

On 2018-07-19 18:16, Matt Ryan wrote:


On July 18, 2018 at 4:16:28 AM, Julian Reschke (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

Re: Supporting direct binary access - PR submitted

[Matt Ryan]

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

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

Re: Supporting direct binary access - PR submitted

[Julian Reschke]

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?


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

Re: Supporting direct binary access - PR submitted

[Marcel Reutegger]

On 18.07.18 06:40, Julian Reschke wrote:

On 2018-07-18 04:09, Matt Ryan wrote:

I’ve changed the code to use URIs instead of URLs.

Regarding the HTTP-specific naming:  The latest iteration of the API 
requires some HTTP-specific elements that need to be able to be set on 
download URIs.  More specifically, these are elements that the 
implementation directs a service provider to set headers to certain 
values on responses to requests for the signed download URIs.  These 
are things like being able to set the response Content-Type or 
Content-Disposition header for example.  (This is discussed further in 
OAK-7637.)


As a result I do think it is evolving to be a bit HTTP-specific.

Are there specific concerns with the naming as it is?


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?


Regards
 Marcel

Re: Supporting direct binary access - PR submitted

[Julian Reschke]

On 2018-07-18 04:09, Matt Ryan wrote:

I’ve changed the code to use URIs instead of URLs.

Regarding the HTTP-specific naming:  The latest iteration of the API 
requires some HTTP-specific elements that need to be able to be set on 
download URIs.  More specifically, these are elements that the 
implementation directs a service provider to set headers to certain 
values on responses to requests for the signed download URIs.  These are 
things like being able to set the response Content-Type or 
Content-Disposition header for example.  (This is discussed further in 
OAK-7637.)


As a result I do think it is evolving to be a bit HTTP-specific.

Are there specific concerns with the naming as it is?


I would say that these are not *necessarily* HTTP-specific, and thus we 
should try to define them in a generic way.


Best regards, Julian

Re: Supporting direct binary access - PR submitted

[Matt Ryan]

I’ve changed the code to use URIs instead of URLs.

Regarding the HTTP-specific naming:  The latest iteration of the API
requires some HTTP-specific elements that need to be able to be set on
download URIs.  More specifically, these are elements that the
implementation directs a service provider to set headers to certain values
on responses to requests for the signed download URIs.  These are things
like being able to set the response Content-Type or Content-Disposition
header for example.  (This is discussed further in OAK-7637.)

As a result I do think it is evolving to be a bit HTTP-specific.

Are there specific concerns with the naming as it is?


On June 28, 2018 at 4:09:26 AM, Julian Reschke (julian.resc...@gmx.de)
wrote:

On 2018-06-27 12:22, Bertrand Delacretaz wrote:
> On Wed, Jun 27, 2018 at 9:43 AM Julian Reschke 
wrote:
>> ...Is the feature really tied to HTTP(s)? I don't think so. And if a
future
>> platform used a different protocol, the API wouldn't really need to
change...
>
> +1, this is probably more about URIs than HTTP URLs.
>
> -Bertrand

Well, switching into pedantic mode, ...

The term "URL" is not the issue here. Even if it wasn't an HTTP(s) URL,
it would still need to be a locator-typed URI for the functionality to
work.

Best regards, Julian

Re: Supporting direct binary access - PR submitted

[Julian Reschke]

On 2018-07-13 22:55, Matt Ryan wrote:

Hi,

I have updated the PR based on feedback from Julian and Bertrand as well 
as review from the Oak team with some API changes.  Please let me know 
what more I need to do, thanks!


https://github.com/apache/jackrabbit/pull/59
...


Could you please generate a patch that contains just the final version 
of the code and attach it to the Jackrabbit ticket?


Best regards, Julian

Re: Supporting direct binary access - PR submitted

[Matt Ryan]

Hi,

I have updated the PR based on feedback from Julian and Bertrand as well as
review from the Oak team with some API changes.  Please let me know what
more I need to do, thanks!

https://github.com/apache/jackrabbit/pull/59



On June 28, 2018 at 4:09:26 AM, Julian Reschke (julian.resc...@gmx.de)
wrote:

On 2018-06-27 12:22, Bertrand Delacretaz wrote:
> On Wed, Jun 27, 2018 at 9:43 AM Julian Reschke 
wrote:
>> ...Is the feature really tied to HTTP(s)? I don't think so. And if a
future
>> platform used a different protocol, the API wouldn't really need to
change...
>
> +1, this is probably more about URIs than HTTP URLs.
>
> -Bertrand

Well, switching into pedantic mode, ...

The term "URL" is not the issue here. Even if it wasn't an HTTP(s) URL,
it would still need to be a locator-typed URI for the functionality to
work.

Best regards, Julian

Re: Supporting direct binary access - PR submitted

[Julian Reschke]

On 2018-06-27 12:22, Bertrand Delacretaz wrote:

On Wed, Jun 27, 2018 at 9:43 AM Julian Reschke  wrote:

...Is the feature really tied to HTTP(s)? I don't think so. And if a future
platform used a different protocol, the API wouldn't really need to change...


+1, this is probably more about URIs than HTTP URLs.

-Bertrand


Well, switching into pedantic mode, ...

The term "URL" is not the issue here. Even if it wasn't an HTTP(s) URL, 
it would still need to be a locator-typed URI for the functionality to work.


Best regards, Julian

Re: Supporting direct binary access - PR submitted

[Bertrand Delacretaz]

On Wed, Jun 27, 2018 at 9:43 AM Julian Reschke  wrote:
> ...Is the feature really tied to HTTP(s)? I don't think so. And if a future
> platform used a different protocol, the API wouldn't really need to change...

+1, this is probably more about URIs than HTTP URLs.

-Bertrand

Re: Supporting direct binary access - PR submitted

[Julian Reschke]

On 2018-06-27 01:50, Matt Ryan wrote:

Hi,

I  have submitted a pull request for a new API feature in jackrabbit-api 
at [0].  This addition is intended for use by a new proposed feature for 
Oak that allows a client to directly upload or download binaries to/from 
a supporting configured blob storage, as described at [1].  A correlated 
Oak pull request using this new capability of Jackrabbit is at [2].  (Of 
course the PR at [2] won’t build without the change; the original PR 
prior to making the change to jackrabbit-api is at [3] if you want to 
pull it and try to run it to see how it works.)


Please take a look and let me know what I need to do for this change to 
be accepted.

...


Here's a question about *naming*.

Is the feature really tied to HTTP(s)? I don't think so. And if a future 
platform used a different protocol, the API wouldn't really need to change.


So maybe all of these interfaces should be named something like 
"BinaryAccess*"?


Best regards, Julian