I think there are two parts to be discussed: a) whether to directly code this into the get servlet b) how to mark the resource as being handled this way
I think a) makes sense, it's a central place and allows any resource provider to use it. However, this is also the problem I see :) For each and every resource the adaption is tried, punishing basically every get request handled by this. This might be neglectable, but we should think about it. For b) I think its good to use an approach which does not require new API. However, any resource could somehow implement adaption to a URI. That might be a URI which can only be resolved by a custom URI handler or it might be a URI which can't be resolved at all or it might be an external URI in any form. For example the full URI to access this resource. So if a redirect would happen to this URI, it would be an endless loop. So just adapting to a URI might not be enough to detect this case. I'm just throwing in a wild idea which I haven't thought fully through yet to foster a discussion: what about we add an ExternalizableInputStream to our API. It extends InputStream by a getURI() method. In the get servlet we adapt to InputStream as today. If it is an instance of ExternalizableInputStream getURI is called, if not, the input stream is used (if provided). This would solve the potential performance problem of a) and gives a clear opt-in for b). Regards Carsten Ian Boston wrote > Hi, > > Background: > OAK-6575 adds support for a Oak DataStore to implement a service > implementing org.apache.jackrabbit.oak.api.conversion.URIProvider which > converts a JCR Value to a URI. The implementation in OAK-6575 is for the > Oak S3 DataStore to convert to a CloudFront signed url as detailed in [1]. > The URI the URIProvider emits in this case expires quickly (< 60s), only > allows GET and is only issued to a JCR session that can read the binary. It > is intended to be used as a redirect, the flow being. > > Client > Sling -> GET <binaryURL> > <- redirect to CF sifgned url > Client -> CF -> GET <CF signed URL> > > To patch[2] has been discussed at length on Oak and now is close to being > acceptable. > > To make this work in Sling requires a patch to Sling, which needs > discussion. The assumptions are that it should work seamlessly and not > require any core component to depend on the Oak API. One patch is [3]. It > adds a new bundle that adds and AdapterFactory that adapts from Resource to > URI. It tries all URIProviders registered by Oak and if one provides a URI. > > Inside the Get Servlets streaming helper, if a resource is adaptable to a > URI, that URI is used as a redirect rather than streaming the binaries. > > I think this patch needs discussion before being committed, hence this > thread. > > Best Regards > Ian > > > > 1 > http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/PrivateContent.html > 2 > https://github.com/ieb/jackrabbit-oak/compare/trunk...ieb:OAK-6575-3?expand=1 > 3 https://github.com/apache/sling/compare/trunk...ieb:OAK-6575-3?expand=1 > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
