allow setting default caching options in cases where upstream has no caching directives

[dohomi]

Hi,

I just played around with the imageproxy and looked up what kind of headers are send down to the browser. I realized that expiration is missing. Is it somehow possible to enable them?

I'm using -cache s3 storage and there the cache-header is missing for the objects. Is there any way to append them with the expiration and/or cache-control on upload?

Thanks

[dohomi]

I was looking into the aws go source (https://github.com/aws/aws-sdk-go/blob/master/service/s3/s3manager/upload.go)

	CacheControl *string `location:"header" locationName:"Cache-Control" type:"string"`

Is it possible to set CacheControl inside of the variables of the proxy somehow?

[dohomi]

After a long journey of researching I found out that the images I scaled didn't have a cache-header. It would be nice if a config could be made to set these in case they are missing:

copyHeader(w.Header(), resp.Header, "Cache-Control", "Last-Modified", "Expires", "Etag", "Link")

[willnorris]

Currently, imageproxy passes along the same caching headers that the original image has (or at least it should... if it's not, then that's a bug). I'm not opposed to having a setting that allowed setting a default expiration time, so long as upstream instructions like Cache-Control: no-cache are still respected. See existing discussion in #28.

[dohomi]

@willnorris the idea would be to have the power to overwrite the default behaviour. I use for example an image repository where no cache-control headers are present. This means that the use of this imageproxy only can be used if I manipulate the cache-control response before the delivery.

Currently I do this with lambda in AWS but I'd like to see this kind of feature inside of the imageproxy already - otherwise the whole caching mechanism is not working.

[dohomi]

closing this in favor for #28