Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] Allow to ignore non-image files (pdf, webm, mp4, mp3, etc.) #387

Open
Vadorequest opened this issue Oct 10, 2022 · 5 comments
Open
Assignees

Comments

@Vadorequest
Copy link

Is your feature request related to a problem? Please describe.
I want to use the CDN as a multi-purpose CDN, I wish it would behave differently when loading a PDF file, for instance

https://cdn.the-funding-place.unly.org/exe-v4/ece-v4-flyer-partenariat-caisse-depargne455.pdf will show an error, but I'd like to prompt a download instead.

It doesn't really make sense to use multiple CDN for different file types, it makes things more complex to manage.
So, I believe we should have a way to make the app behave differently depending on the file being manipulated.

The most logical choice would be that any type that isn't handled would prompt a download, I don't think we need more than that at this time, it'd be a good default behavior.

Describe the feature you'd like
Prompt a download when a file type isn't handled (pdf, etc.)

Additional context
This doesn't seem to be officially supported, but here are a few workarounds:

  • can't bypass non-image file #49 (comment) Change the code to do something different (this should probably be added to this repository to provide good sensible default while still allowing people to customise even deeper). Unfortunately, this workaround is poorly documented and I'm not sure what I should do.
  • can't bypass non-image file #49 (comment) Add bypasses on the CloudFront Behaviors manually, this shouldn't be necessary

Could we get a better default behavior?

@dougtoppin
Copy link
Contributor

We will add an evaluation of this to our backlog

@Vadorequest
Copy link
Author

My vision has evolved a bit since posting this, and I believe SIH should be something that would act as a "drop-in", and basically extend the capabilities of a standard CDN, not change its behavior.

Concretely, that'd mean that any kind of file that isn't supported by SIH (or Sharp) should just behave as it would when not using SIH.

This way, we could replace an existing CDN by SIH without fearing any kind of regression. That would be the best of both world, as we could use the powerful SIH feature if we want, or simply use it as a normal CDN.

The way it works right now, I had to deploy two CDN for my use-case, as modifying the default SIH behavior was too hard to do. One is used for all files, while SIH is meant to be used for images.

@github-actions
Copy link

This issue 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.

@chrisAllfasteners
Copy link

Any update?

@simonkrol
Copy link
Member

Hi @chrisAllfasteners and @Vadorequest,

This isn't something we're currently targeting for any upcoming releases, though you could likely make this work on a basic level without too much difficulty.

Something like:

  • Adding a new origin to your CloudFront distribution which points to your S3 bucket
  • Setting up behaviours which match any of the extensions you want to point to SIH and ensuring they point to the existing origin
  • Setting up a new default behaviour which goes to the S3 bucket

One main point to keep in mind is that this would only work if you're using Thumbor-style requests (Not the base64 encoded ones) and you can find a way to match the images you'd like to send to SIH.

Let me know how it goes,
Simon

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants