willnorris / imageproxy

We are serving files from the backend with URLs like "http://example.com/images/some.pdf,1234" and a header Content-Disposition: filename="some.pdf", so if a user wants to save the file it has a "correct" filename.

But the imageproxy is not passing through these headers and I also did not find an option to do so.

Would this be a new feature, is there an existing option to do so or is it not adviced in general to passResponseHeaders.

CC: @handcode

There are a handful of headers we copy from the upstream response...

imageproxy/imageproxy.go

Line 239 in da55ece

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

imageproxy/imageproxy.go

Line 260 in da55ece

copyHeader(w.Header(), resp.Header, "Content-Length")

I'd be fine accepting a patch to add Content-Disposition to that list.

Though I'm kinda curious... you're using imageproxy for PDF files? Why? Just for the https enforcement and caching, I suppose?

We could of course now "simply" include Content-Disposition in line 239, but what do you think about making the list of headers that are copied from the response configurable (--originHeaders option)?

This would then also allow someone to remove unwanted headers such as ETags.
But since I'm not a Go hacker, I can't easily make a patch for it.

And to answer your question about PDFs:
We use a combination of nginx/imageproxy for image processing and media-file chaching (the nginx itself also has a cache to reduce the load on the imageproxy).

The reason to route something like PDFs through the imageproxy (and not directly from the nginx to the origin) is the limitation of the backends. (signed-requests, allowHosts)

Passing response headers