Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

s3 multipart upload parts contain all headers from part PUT requests #5667

Open
2 tasks done
rvdrijst opened this issue Feb 26, 2025 · 0 comments
Open
2 tasks done

s3 multipart upload parts contain all headers from part PUT requests #5667

rvdrijst opened this issue Feb 26, 2025 · 0 comments
Labels

Comments

@rvdrijst
Copy link

rvdrijst commented Feb 26, 2025

Initial checklist

  • 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:

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)

@rvdrijst rvdrijst added the Bug label Feb 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant