Open christoph-kluge opened 3 years ago
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_headers
or 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.
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.
What do you think?