cache and serve gzipped resource if client requests it
I'm wondering if it would be useful to support gzip compression if the Accept-Encoding: gzip header is set. This would probably impact the caching logic, as imageproxy would need to store both the uncompressed and compressed version in cache, and serve it based on the header.
I'm mounting imageproxy as a custom origin for a Cloudfront distritution, and it works great. But Cloudfront will automatically cache different version of the same image based on the Accept-Encoding: gzip header, so if imageproxy supported it, it would just work.
Thoughts? I'd be happy to do some development on it.
impact on caching should be relatively minimal if you just add a Gzip field to the Options struct. I was contemplating doing something similar to convert and return a webp image if the client supported it, but never got to it (also, I don't think there are any webp encoding libraries for go). Idea would be the same though... set the options value based on a request header.
speaking of caching, is this how you're running imageproxy? If so, then it looks like you're running with the in-memory cache which will eventually eat up all your available memory (I think). I suppose I should change the default to use the NopCache that gets used in tests. If you're relying on cloudfront for the caching, then that would probably work fine for you.
Awesome, thanks! Yes, that's how we're running it. I think that NopCache is a great idea for the default. It would at least be a great setting for people who have a CDN in front of the proxy. Is there currently a setting I can use for this, or does it need to be implemented?
there's not setting for it currently, it's just used for tests. I think it would make sense to modify cmd/imageproxy/main.go to make that the default and add a new -memoryCache (or similarly named) flag to use the in-memory cache.
Sounds good to me! I'll jump on the GZIP thing and see how far I get.
@runemadsen is this feature made it into master?
No, definitely not in master. As far as I'm aware, no one is working on it.