[
https://issues.apache.org/jira/browse/HDDS-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752077#comment-17752077
]
Vyacheslav Tutrinov commented on HDDS-9114:
-------------------------------------------
The current implementation of the ETag header response in case of a file's
multipart upload has the next representation for the parts upload request:
{code}
/prefix/key-{UUID}-{timestamp}-{partIndex}
{code}
And the next one for the POST request's reponse to commit parts as a single
file:
{code}
sha256hex(keyNameWithoutPrefix)
{code}
An AWS S3's implementation presents prety the same one for all of the request
to store multipart files, the main similarity is that the tail parts are
similar - *-{partIndex}*
Hence, we can leave parts requests responses as is and update the commit
request's response to provide a similar ETag.
> Provide ETag in a response header on file uploading through s3g
> ---------------------------------------------------------------
>
> Key: HDDS-9114
> URL: https://issues.apache.org/jira/browse/HDDS-9114
> Project: Apache Ozone
> Issue Type: Task
> Components: S3
> Reporter: Vyacheslav Tutrinov
> Assignee: Vyacheslav Tutrinov
> Priority: Major
>
> On uploading a file through s3g an ETag header should be provided:
> * in the case of a single file/part upload it represents MD5 of the file
> content
> * if the file will be uploaded using a multipart upload then the ETag of the
> object is computed as MD5 of all individual part checksums:
> {code}
> // e1 = MD5(part-1)
> // e2 = MD5(part-2)
> // ...
> // eN = MD5(part-N)
> // ETag = MD5(e1 || e2 || e3 ... || eN) || -N
> // For example: ceb8853ddc5086cc4ab9e149f8f09c88-5
> {code}
> Computed ETag should be stored as a key metadata
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
