Add support for `X-Amz-Content-Sha256: STREAMING-UNSIGNED-PAYLOAD-TRAILER` #824

New issue

Open

opened 2024-05-21 06:52:45 +00:00 by crimsonfez · 4 comments

crimsonfez commented

2024-05-21 06:52:45 +00:00

When I configured HTTPS via Caddy I get this error when velero tries to upload a backup.

Response: error 400 Bad Request, Bad request: Invalid content sha256 hash: Invalid character 'S' at position 0

When I use HTTP it does not have this issue even through Caddy.

Here is the log before showing what request failed

PUT /404sys-ord/backups/test5/velero-backup.json?x-id=PutObject

When I configured HTTPS via Caddy I get this error when velero tries to upload a backup. `Response: error 400 Bad Request, Bad request: Invalid content sha256 hash: Invalid character 'S' at position 0` When I use HTTP it does not have this issue even through Caddy. Here is the log before showing what request failed `PUT /404sys-ord/backups/test5/velero-backup.json?x-id=PutObject`

crimsonfez commented

2024-05-21 07:10:44 +00:00

Author

I believe the problem here is related to X-Amz-Content-Sha256: STREAMING-UNSIGNED-PAYLOAD-TRAILER

I believe the problem here is related to `X-Amz-Content-Sha256: STREAMING-UNSIGNED-PAYLOAD-TRAILER`

crimsonfez commented

2024-05-22 07:32:05 +00:00

Author

Turns out the aws library that Velero uses will use this type of content signing only with TLS connections, which is why this is not an issue on HTTP.

👍 1

crimsonfez changed title from ~~`Invalid content sha256 hash` when using HTTPS~~ to Add support for `X-Amz-Content-Sha256: STREAMING-UNSIGNED-PAYLOAD-TRAILER`

2024-05-22 07:33:21 +00:00

tabongobong commented

2024-05-24 10:56:17 +00:00

Turns out the aws library that Velero uses will use this type of content signing only with TLS connections, which is why this is not an issue on HTTP.

This seems to circumvent the issue on the velero side. Same problem seems to also be present in minio https://github.com/vmware-tanzu/velero/issues/7696#issuecomment-2078241888

> Turns out the aws library that Velero uses will use this type of content signing only with TLS connections, which is why this is not an issue on HTTP. This seems to circumvent the issue on the velero side. Same problem seems to also be present in minio https://github.com/vmware-tanzu/velero/issues/7696#issuecomment-2078241888