Will Norris

hmm :confused: Not sure what I'd do in that case, since it hasn't actually been a problem for me personally yet. It's one thing if upstream specifically says "Cache-Control: no-cache",...

Other Cache-Control headers to consider... how should imageproxy handle these? > **no-store** - The cache should not store anything about the client request or server response. > > **no-transform** -...

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

speaking of caching, is [this](https://github.com/oreillymedia/imageproxy/blob/master/Procfile) 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...

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`...

No, definitely not in master. As far as I'm aware, no one is working on it.

Did this get fixed on your end at some point along the way? I still see the issue when proxied through my server, but you seem to have it working...

one problem with this is that the httpcache package caches the entire HTTP response (headers and all), not just the image. So you couldn't just point to the existing cache...

Agreed that this seems related to #80. I hadn't spent a lot of time looking at all the edge cases relating to transparent gifs, so it doesn't surprise me terribly...

we've started to move away from all of the files in testdata (though obviously never finished). But could you go ahead and add this to our newer test case at...