Image expires header

[markuscolourbox]

Issue #, if available:

#345

Description of changes:

• Allow overwriting Expires response header
• Respond with 4xx error when requesting manually expired resource

By setting the { "headers": { "expires": "..." } } value to a UTCTimeString the link can be made time-limited. Useful when combined with signed urls. The set expires takes precedence over S3 Object expires and expired requests get served 403 Forbidden.

We placed the expiry date in the headers section because of semantics, moving it to the root of the request JSON, or renaming it would be simple.

Checklist

• [x] :wave: I have run the unit tests, and all unit tests have passed.
• [ ] :warning: This pull request might incur a breaking change.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[fisenkodv]

@markuscolourbox thank you for your contribution. We will look into it and add it to our backlog.

[defclass]

Hi @markuscolourbox Thanks for the excellent PR. It's entirely possible I'm wrong. I think it would be great if adding expire factor among signature generating and attach the expire field on query string. Someone maybe want to protect time-limited access by using HTTP redirection (eg: HTTP 302).

[markuscolourbox]

Hi @markuscolourbox Thanks for the excellent PR. It's entirely possible I'm wrong. I think it would be great if adding expire factor among signature generating and attach the expire field on query string. Someone maybe want to protect time-limited access by using HTTP redirection (eg: HTTP 302).

We considered this too. The reason we went with the approach we did, is only that the signature so far is only created over the path (the base64 encoded json). This would make the expire field the first & only query parameter to be part of the signature. If this is preferred, I can adjust the PR.

[markuscolourbox]

Does anyone have any opinions on what the header(s) should be called. If we followed the s3 style we could have paths like: /eyJid[...]?&Date=20130721T201207Z&Expires=86400&Signature=[...] where the file expires "Expires"-seconds after "Date". We could also just have /eyJid[...]?Expires=20130721T201207Z&Signature=[...] with expiry on the date in the url.

(Current branch state is WIP, will return after a decision on this was made)

[pbowyer]

@markuscolourbox I prefer the S3 style, purely for ease of debugging as it makes the two values obvious. But either work for me - just looking forward to this feature getting included!

[jancolourbox]

@fisenkodv what is the ETA of getting PR accepted. As noted by @markuscolourbox we are open to change the format to match AWS's preferences - just let us know.

[github-actions[bot]]

This pr has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.

[pbowyer]

@aws-solutions-github-bot Please leave open

[simonkrol]

Hi @markuscolourbox,

I'm evaluating this change now, and so far I think it makes sense as an addition in the Serverless Image Handler. My main concern here is that including the expires field will cause a notable decrease to the cache hit rate, requiring that we reprocess an image even if the previously generated version isn't expired yet (Since the signature/expires parameters would change and are used when caching). This isn't a deal breaker since it would only affect customers using this feature but is worth noting.

Let me know if you have any thoughts, Simon

[simonkrol]

Hi @markuscolourbox, We've decided to include this feature in the next major release of SIH. Our internal policies have us merge the code manually, but you'll see your profile and a link to this PR included in the External Contributors section towards the bottom of the readme once the release is out.

Thanks for your contributions to SIH :) Simon