It seems like "How to test this PR?" just causes a regression the way you present it. Does AWS S3 do the same? Is there a bug in mc?

It seems like "How to test this PR?" just causes a regression the way you present it. Does AWS S3 do the same? Is there a bug in mc?

bug in AWS S3 @klauspost

It looks like @jiuker didn't add the comment that there is a bug in AWS S3, we should write that here in this code path.

Add tests with samples referenced against AWS, so sending [xyz...] in the header should produce the same response [qwe...] as AWS. If you do that on the Server we are fine.

Also fix up minio-go, so it is round-trip safe. That means you get back what you send. If you did the server correctly, that should work against both AWS and MinIO servers.

Add tests with samples referenced against AWS, so sending [xyz...] in the header should produce the same response [qwe...] as AWS. If you do that on the Server we are fine.

@klauspost AWS returns wrong characters - here is missing comment from the PR that I had asked @jiuker to add.

// For metadata values like "ö", "ÄMÄZÕÑ S3", and "öha, das 你好 sollte eigentlich
// funktionieren", tested against a real AWS S3 bucket, S3 may encode incorrectly. For
// example, "ö" was encoded as =?UTF-8?B?w4PCtg==?=, producing invalid UTF-8 instead
// of =?UTF-8?B?w7Y=?=. This mirrors errors like the ä½ in another string.
//
// S3 uses B-encoding (Base64) for non-ASCII-heavy metadata and Q-encoding
// (quoted-printable) for mostly ASCII strings. Long strings are split at word
// boundaries to fit RFC 2047’s 75-character limit, ensuring HTTP parser
// compatibility.
//
// However, this splitting increases header size and can introduce errors, unlike Go’s
// mime package in MinIO, which correctly encodes strings with fixed B/Q encodings,
// avoiding S3’s heuristic-driven issues.
//
// For MinIO developers, decode S3 metadata with mime.WordDecoder, validate outputs,
// report encoding bugs to AWS, and use ASCII-only metadata to ensure reliable S3 API
// compatibility.

Add tests with samples referenced against AWS, so sending [xyz...] in the header should produce the same response [qwe...] as AWS. If you do that on the Server we are fine.添加测试，其中包含参考 AWS 的示例，因此发送[xyz.]在 header 中应该产生相同的响应[qwe...]作为 AWS。如果你在服务器上这样做，我们就很好。

@klauspost AWS returns wrong characters - here is missing comment from the PR that I had asked @jiuker to add.AWS 返回错误的字符-这里是我要求添加的 PR 中缺少的评论。

// For metadata values like "ö", "ÄMÄZÕÑ S3", and "öha, das 你好 sollte eigentlich
// funktionieren", tested against a real AWS S3 bucket, S3 may encode incorrectly. For
// example, "ö" was encoded as =?UTF-8?B?w4PCtg==?=, producing invalid UTF-8 instead
// of =?UTF-8?B?w7Y=?=. This mirrors errors like the ä½ in another string.
//
// S3 uses B-encoding (Base64) for non-ASCII-heavy metadata and Q-encoding
// (quoted-printable) for mostly ASCII strings. Long strings are split at word
// boundaries to fit RFC 2047’s 75-character limit, ensuring HTTP parser
// compatibility.
//
// However, this splitting increases header size and can introduce errors, unlike Go’s
// mime package in MinIO, which correctly encodes strings with fixed B/Q encodings,
// avoiding S3’s heuristic-driven issues.
//
// For MinIO developers, decode S3 metadata with mime.WordDecoder, validate outputs,
// report encoding bugs to AWS, and use ASCII-only metadata to ensure reliable S3 API
// compatibility.

Added

@harshavardhana Yes. I saw your comment and asked for clarification since only half of it makes sense.

This should still have tests, either here or in mint.

@harshavardhana Yes. I saw your comment and asked for clarification since only half of it makes sense.

This should still have tests, either here or in mint.

Will have test for mint. @klauspost