Add support to add additional response headers based on custom metadata
In some use cases you would like to add custom headers. I think Cache-Control would be very beneficial in many scenarios. Additionally there might be some even more headers for custom use-cases.
In the first place I support more common headers (hardcoded) which are potentially frequently used in combination with s3:
-
Cache-Control -
Pragma(I think there is still ppl using this) -
Expires(I think there is still ppl using this)
And in a second iteration I would like to add configuration for custom headers.
s3proxy {
allow_headers {
x-custom-header-1
x-custom-header-2
x-custom-header-3
}
}
What do you think?
So allow-headers would just be a "safety" thing to key any random headers someone put on an S3 object from being sent along as well?
My implementation in the PR went from "only selected headers from the object" to "all custom headers on the object".
According to the new situation I think that a deny_headersor skip_headers would be more suitable.
A little bit more sophisticated solution could be very close to what was implemented in the logging module. Specify filters on fields: https://caddyserver.com/docs/caddyfile/directives/log#examples
I could think that we could re-use this and apply such filters to the headers for full customization to support all needs one could have.
s3proxy {
headers {
# remove headers on the S3Client request (dunno if this example makes sense)
request>Authorization delete
request>headers>Pragma delete
# remove/deny custom headers on the response
response>Cache-Control delete
response>X-Debug-Header-123 delete
# add a custom-header "hit" to the response
response>X-Cache-S3-Proxy "hit"
}
}
I like this idea. In fact, one could (and should) implement auth in caddy if s3 proxy is exposed to the internet and they have enable_put on.
This feature would enable the to remove auth related headers before passing them on to AWS. In fact, now that all headers are passed though this might be quite important.