You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I understand this is a bug report and questions should be posted in the Community Forum
I searched issues and couldn’t find anything (or linked relevant results below)
Link to runnable example
No response
Steps to reproduce
I'm running Minio with default settings (docker image minio/minio:RELEASE.2025-02-18T16-25-55Z).
I'm using the latest versions of Uppy and the AwsS3 plugin (@uppy/aws-s3": "4.2.3", "@uppy/core": "4.4.2").
A PUT request (for each part) returns a bunch of headers:
Somehow, these headers make their way to the AwsS3Part (even though this should only contain PartNumber and ETag (and possibly Size)
All these extra headers are then sent to the backend when completing the multipart upload, leading to an error (only PartNumber and ETag are expected so this breaks).
The headers keys have all been lowercased, so ETag and etag are both in there.
What makes this more confusing: if I pause and resume the multipart upload, parts that were uploaded before the pause do not contain the header fields:
Expected behavior
I expect the Parts to adhere to their interface and only include PartNumber and ETag, regardless of the headers returned by the PUT request.
This was the behavior with my previous Uppy 3.13 with aws-s3 3.6, which did not have this problem.
Actual behavior
The parts contain extra fields that mirror the (lowercased) header fields from the corresponding PUT requests, and those fields are unexpected.
As a workaround I now intercept the completeMultipartUpload call and strip out all unexpected fields but this feels like a step that should not be necessary (and wasn't necessary before)
The text was updated successfully, but these errors were encountered:
Initial checklist
Link to runnable example
No response
Steps to reproduce
I'm running Minio with default settings (docker image minio/minio:RELEASE.2025-02-18T16-25-55Z).
I'm using the latest versions of Uppy and the AwsS3 plugin (@uppy/aws-s3": "4.2.3", "@uppy/core": "4.4.2").
A PUT request (for each part) returns a bunch of headers:
Somehow, these headers make their way to the
AwsS3Part
(even though this should only containPartNumber
andETag
(and possiblySize
)All these extra headers are then sent to the backend when completing the multipart upload, leading to an error (only
PartNumber
andETag
are expected so this breaks).The headers keys have all been lowercased, so
ETag
andetag
are both in there.What makes this more confusing: if I pause and resume the multipart upload, parts that were uploaded before the pause do not contain the header fields:
Expected behavior
I expect the Parts to adhere to their interface and only include
PartNumber and ETag
, regardless of the headers returned by the PUT request.This was the behavior with my previous Uppy 3.13 with aws-s3 3.6, which did not have this problem.
Actual behavior
The parts contain extra fields that mirror the (lowercased) header fields from the corresponding PUT requests, and those fields are unexpected.
As a workaround I now intercept the
completeMultipartUpload
call and strip out all unexpected fields but this feels like a step that should not be necessary (and wasn't necessary before)The text was updated successfully, but these errors were encountered: