-
Notifications
You must be signed in to change notification settings - Fork 484
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
Comments
There are a handful of headers we copy from the upstream response... Line 239 in da55ece
Line 260 in da55ece
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 This would then also allow someone to remove unwanted headers such as ETags. And to answer your question about PDFs: 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) |
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
The text was updated successfully, but these errors were encountered: