Upload misses implementation for a few headers

[chrisguttandin]

Checkboxes for prior research

• I've gone through Developer Guide and API reference
• I've checked AWS Forums and StackOverflow.
• I've searched for previous similar issues and didn't find any solution.

Describe the bug

I'm trying to use Upload from lib-storage with the IfNoneMatch param. It throws an error saying that it is not yet implemented.

Regression Issue

• Select this option if this issue appears to be a regression.

SDK version number

@aws-sdk/lib-storage@3.1044.0

Which JavaScript Runtime is this issue in?

Node.js

Details of the browser/Node.js/ReactNative version

v22.22.2

Reproduction Steps

This will trigger the error:

import { S3Client } from '@aws-sdk/client-s3';
import { Upload } from '@aws-sdk/lib-storage';

const s3Client = new S3Client(/* ... */);
const upload = new Upload({ client: s3Client, params: { Body, Bucket: '...', IfNoneMatch: '*', Key: '...' } });

await upload.done();

Observed Behavior

It will throw an error.

Expected Behavior

I think this could be implemented.

Possible Solution

It looks like the params are internally handled already. The Body for example gets replaced ...

aws-sdk-js-v3/lib/lib-storage/src/Upload.ts

Line 146 in a664335

const params = { ...this.params, Body: dataPart.data };

... or set to undefined ...

aws-sdk-js-v3/lib/lib-storage/src/Upload.ts

Line 227 in a664335

const createCommandParams = { ...this.params, Body: undefined };

... if necessary. I think a similar thing could be done for the params that should only be set for the PutObjectCommand and CompleteMultipartUploadCommand respectively.

Additional Information/Context

I'm happy to provide PR for this if it helps.

[aBurmeseDev]

Hi @chrisguttandin, thanks for checking in! I gave this a shot but couldn't actually repro it.

I wired up Upload with IfNoneMatch: "*" on a 6 MiB body (so it takes the multipart path) and intercepted the requests. The header only ends up on CompleteMultipartUpload which S3 does accept for conditional writes and CreateMultipartUpload and UploadPart don't carry it. Could you share the exact error message/stack you're seeing, and confirm which SDK version + body size? Also worth checking whether it's specifically IfNoneMatch or one of the other conditional params, wondering if the "not yet implemented" is coming back from S3 itself rather than the SDK.

[danyalahmed1995]

@aBurmeseDev Hi , idk if you checked the opened PR #8029 I believe there’s still a boundary issue there.

The PR fixes the IfNoneMatch leak by replacing the broad ...this.params spread into UploadPartCommand, but the new allowlist still forwards top-level Checksum* fields into every part upload. I tested a temporary regression case with top-level ChecksumSHA256, and both mocked UploadPartCommand calls received the same value.

That seems like the same class of problem as ContentMD5: the value can be object-level at the Upload API boundary, while UploadPartCommand treats it as per-part data. So I don’t think the PR #8029 fully closes this yet without tightening that allowlist further.

[danyalahmed1995]

So I was able to open a PR #8042 with a narrower UploadPartCommand params boundary.

It covers the original IfNoneMatch multipart case and also avoids forwarding concrete object-level Checksum* values into each part upload. I added unit coverage for the single PUT path, multipart part params, and completion params.

I did a local serializer-path check with a fake endpoint/custom request handler: multipart UploadPart requests no longer carried object-level if-none-match, content-md5, or the object-level x-amz-checksum-sha256, while the single PutObject path still preserved those object-level params.

Attached a log below.

aws_sdk_js_v3_8020_serializer_verification_sanitized.md

[chrisguttandin]

Hi @aBurmeseDev, thanks for trying to reproduce the bug. You're right. I can confirm that the error is caused by the "S3 compatible" service I was using for this particular project. It all works as expected when uploading to a bucket on AWS. Sorry for that. I should have checked this before filing the issue.

[aBurmeseDev]

Hi @chrisguttandin, no worries at all and thanks for following up! Glad to hear it's working as expected. l'll go ahead and close this one out. Feel free to open a new issue if you run into anything else.