Why is cache_control header blacklisted for generation of signed URLs?

[toaster]

Hi there,

for #1026 a list of headers were excluded from signature for various reasons.
One of them (cache_control) is used by me in presigned URLs and I want to rely upon it to ensure that uploaded objects have the proper cache control settings.
For me this is a blocker for upgrading beyond 2.2.5. Of course I could monkey patch the signer but that is not really what I want to do.
If it is really necessary to have this header excluded from signature it may be a solution to make its exclusion optional.

[awood45]

So, if I understand you correctly, you're relying on the signature to show that the cache-control header is not modified by your customer?

In any case, I'll re-check that it needs to be on the blacklist, although our direction is moving towards a whitelist of headers in the future, potentially.

I think there's a feature request here to whitelist headers for signing. I think it's fair for you to say: "Sign this header, I understand that I'm now responsible for ensuring it is not modified in transit to the server, and that there will be an error if it is."

[toaster]

Yes, you understood me correctly. And yeah, that whitelist would be totally okay for me.

[awood45]

Adding to feature request backlog. Will also take a PR for this if you want to take a crack at it.

[toaster]

Hi there!

Due to this issue we are still stuck at SDK version 2.2.5. We now want to use the upload acceleration which is not supported by 2.2.5 AFAICS.
Is there any chance that #1228 will be merged any time soon?

[awood45]

I've added review notes to that PR, and we'll work on getting that in.

[toaster]

Hi again,

we worked around our upload acceleration issue with 2.2.5 by simply patching the URL.
But now we want to use signed CloudFront URLs. But, alas, the Aws::CloudFront::UrlSigner does not exist in 2.2.5.
This problem has now evolved from “annoying” to “blocker” for us.
When will the PR get merged?