gateway: don't use encrypted ETags for If-Match (#11400)
This commit fixes a bug in the S3 gateway that causes GET requests to fail when the object is encrypted by the gateway itself. The gateway was not able to GET the object since it always specified a `If-Match` pre-condition checking that the object ETag matches an expected ETag - even for encrypted ETags. The problem is that an encrypted ETag will never match the ETag computed by the backend causing the `If-Match` pre-condition to fail. This commit fixes this by not sending an `If-Match` header when the ETag is encrypted. This is acceptable because: 1. A gateway-encrypted object consists of two objects at the backend and there is no way to provide a concurrency-safe implementation of two consecutive S3 GETs in the deployment model of the S3 gateway. Ref: S3 gateways are self-contained and isolated - and there may be multiple instances at the same time (no lock across instances). 2. Even if the data object changes (concurrent PUT) while gateway A has download the metadata object (but not issued the GET to the data object => data race) then we don't return invalid data to the client since the decryption (of the currently uploaded data) will fail - given the metadata of the previous object.master
parent
8c663f93f7
commit
838d4dafbd
Loading…
Reference in new issue