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

Passing response headers #387

Open
schmunk42 opened this issue Sep 20, 2023 · 2 comments
Open

Passing response headers #387

schmunk42 opened this issue Sep 20, 2023 · 2 comments

Comments

@schmunk42
Copy link

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

@willnorris
Copy link
Owner

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

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

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?

@handcode
Copy link

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)

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

No branches or pull requests

3 participants