uppy icon indicating copy to clipboard operation
uppy copied to clipboard

s3 multipart upload parts contain all headers from part PUT requests

Open binairo opened this issue 10 months ago • 0 comments

Initial checklist

  • [x] I understand this is a bug report and questions should be posted in the Community Forum
  • [x] 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:

Image

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.

Image

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:

Image

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)

binairo avatar Feb 26 '25 09:02 binairo