hesela.devConditional write
A conditional write changes a resource only when a server-evaluated precondition, such as a matching entity tag or the absence of a current object, holds.
For Amazon S3 general-purpose buckets, If-Match on PutObject or CompleteMultipartUpload compares the current destination object's ETag, while If-None-Match: * requires no current object. This is an object-level precondition, not a multi-object transaction or a test that no intervening write ever happened. Client-side checking followed by an unconditional upload does not provide the same protection. An ETag condition validates the representation under the service's ETag rules, not every metadata field or application invariant.
Relations
- related
- object-storage, entity-tag, multipart-upload, compare-and-swap
Advantages
- An If-Match precondition can reject a stale replacement instead of silently overwriting a representation whose validator has changed. [1, 2]
- If-None-Match: * lets an S3 writer require that the destination has no current object at the write operation, without a separate check-then-create race. [1, 2]
Limitations
- A mismatched ETag or an existing current object under If-None-Match: * causes S3 to return 412; a conflicting operation can return 409, and blindly refreshing the ETag without reconciling stale content can lose an update. [3, 6]
- After a 409 from CompleteMultipartUpload, S3 requires a new upload ID and re-upload of every part; retry rules therefore differ from PutObject. [3, 4]
- In versioned S3 buckets, If-None-Match: * permits a write when the current version is a delete marker, even if older versions remain; If-Match fails with 404 when there is no current object or the current version is a delete marker. [2]
- Strong S3 read-after-write consistency does not make a separate read-modify-write sequence atomic, and S3 does not provide atomic updates across multiple keys. [5, 6]