Hi, On 14 September 2017 at 06:02, Julian Reschke <[email protected]> wrote:
> On 2017-09-14 14:54, Ian Boston wrote: > >> Hi, >> >> On 14 Sep 2017 12:22 am, "Julian Reschke" <[email protected] <mailto: >> [email protected]>> wrote: >> >> On 2017-09-14 01:29, Ian Boston wrote: >> >> Hi, >> Here is an updated patch. >> >> https://github.com/apache/sling/compare/trunk...ieb:OAK-6575 >> -3-1?expand=1 >> <https://github.com/apache/sling/compare/trunk...ieb:OAK-657 >> 5-3-1?expand=1> >> >> Best Regards >> Ian >> >> >> 1) I think it would be good to only redirect HEAD and GET (may >> already be the case...) >> >> >> This is already the case, but looking at the code, should it redirect for >> HEAD, or should HEAD still be served by Sling ? (I havent checked the >> spec). Sling has all the information needed for a HEAD response, although >> it might not be exactly the same as the HEAD response from the target of >> the redirect. If the target of the redirect is CloudFront, then I would >> expect it to respond with headers consistent with its behaviour. >> > > Realistically, callers would be interested in media type and content > length. For these, both should be correct, right? In which case I think not > doing the redirect would be the simpler approach. > > I would also expect the target of the redirect to change, as the signature >> in the query params will change on each fresh redirect. Is that going to >> cause a problem ? >> > > It the client keeps the URI and then does a GET, would it still work? > While the TTL is still valid, yes. After that no, but this is implementation specific, and controlled by Oak (or the DS implementation inside Oak) In the case of CloudFront signed urls, the signature of the URL with a canned policy. The policy is enforced by CloudFront and (afaik) allows both HEAD and GET requests, but not any other. So a client could store the redirect and use it later, provided the signature had not expired. The client could not use the URL to perform a POST or anything else. It is possible to sign a URL with custom policies, but Oak wont do this, probably ever. Best Regards Ian > > ... >> > > Best regards, Julian >
