Complement to the measurement in the description (OVHcloud Object Storage, eu-west-par, 2026-10-12): the "UploadPartCopy, x-amz-copy-source-if-match, 200 / 412" row holds only for a source uploaded in a single request. For a source uploaded in several parts (ETag ending with -<part count>), the condition always fails with 412, with the ETag returned by HEAD, without its quotes, and with the MD5 of the whole content; x-amz-copy-source-if-none-match with a wrong ETag and no condition both answer 200.
Consequences for this issue:
A probe of UploadPartCopy has to use a source uploaded in several parts, otherwise it reports a support that XWiki can't use (large blobs are uploaded in several parts, and only large blobs are copied with UploadPartCopy).
For the one-part multipart copy idea, the atomicity comes from If-None-Match on CompleteMultipartUpload; the source precondition on UploadPartCopy can't be relied on with such services.
XCOMMONS-3823 now puts the UploadPartCopy condition under store.s3.conditionalCopies (with If-None-Match on CopyObject), and store.s3.conditionalWrites covers If-None-Match on PutObject and CompleteMultipartUpload.
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
