Pin multipart Content-Type / Content-Transfer-Encoding case folding to Locale.US by daguimu · Pull Request #16768 · netty/netty

daguimu · 2026-05-08T01:02:49Z

Problem

Two spots in the HTTP multipart codec normalize a header value with String.toLowerCase() without an explicit Locale, then compare the result to lowercase ASCII constants. The JVM default Locale governs that call, and on a Turkish (tr_TR) JVM the ASCII 'I' lowercases to 'ı' (U+0131). A perfectly valid uppercase form silently misses the comparison.

Concretely on a Turkish-locale JVM:

HttpPostMultipartRequestDecoder decoding a part with Content-Transfer-Encoding: BINARY (uppercase, RFC 2045 §6.1 says mechanism tokens are case-insensitive) lowercases the value to "bınary", fails the equality check against the binary / 7bit / 8bit constants, and throws ErrorDataDecoderException: TransferEncoding Unknown: bınary.
HttpPostRequestEncoder.finalizeRequest() skipping a pre-existing Content-Type: MULTIPART/form-data; boundary=... header (mixed case is allowed by the Content-Type ABNF, RFC 7231 §3.1.1.1) lowercases the value to "multıpart/...", misses the startsWith("multipart/form-data") check, and the original mixed-case header survives alongside the freshly-built multipart Content-Type the encoder is about to add. The outgoing request ends up with two Content-Type headers.

The values being compared against are lowercase ASCII tokens and have no business consulting the JVM locale.

Fix

Pin both String.toLowerCase() calls to Locale.US:

codec-http/src/main/java/io/netty/handler/codec/http/multipart/HttpPostMultipartRequestDecoder.java — getFileUpload(String delimiter) lowercases the Content-Transfer-Encoding value before matching it against BIT7 / BIT8 / BINARY mechanism tokens.
codec-http/src/main/java/io/netty/handler/codec/http/multipart/HttpPostRequestEncoder.java — finalizeRequest() lowercases each existing Content-Type before checking if it is the multipart or application/x-www-form-urlencoded form (which the encoder is responsible for setting fresh).

Tests

Change Point	Test
Decoder Content-Transfer-Encoding lowercase under Turkish	`HttpPostMultiPartRequestDecoderTest.testUppercaseBinaryTransferEncodingUnderTurkishLocale` — installs the Turkish locale (restored in `finally`), feeds a multipart body with `Content-Transfer-Encoding: BINARY`, and asserts the file part decodes successfully. Without the fix this throws `TransferEncoding Unknown: bınary`.
Encoder Content-Type lowercase under Turkish	`HttpPostRequestEncoderTest.testFinalizeRemovesPreexistingMultipartContentTypeUnderTurkishLocale` — pre-sets `Content-Type: MULTIPART/form-data; boundary=preexisting`, runs the encoder under the Turkish locale, and asserts only one Content-Type header survives. Without the fix the request ends up with two Content-Type headers.

Both tests fail deterministically on the unfixed code (one as an assertion failure, the other as a thrown ErrorDataDecoderException) and pass after the Locale.US change.

Verification:

mvn -pl codec-http -am test \
  -Dtest='HttpPostRequestEncoderTest#testFinalizeRemovesPreexistingMultipartContentTypeUnderTurkishLocale,HttpPostMultiPartRequestDecoderTest#testUppercaseBinaryTransferEncodingUnderTurkishLocale' \
  -Dsurefire.failIfNoSpecifiedTests=false
# Tests run: 2, Failures: 0, Errors: 0, Skipped: 0

Impact

Behavior on en/CJK/most locales: unchanged (the previous default-locale lowercase already produced ASCII).
Behavior on Turkish (and other locales with non-ASCII case mappings): a multipart upload with uppercase Content-Transfer-Encoding: BINARY now decodes instead of throwing; an outgoing multipart request with a pre-existing mixed-case Content-Type: MULTIPART/... no longer leaks a duplicate Content-Type header.
API: no signature change. All callers continue through the existing public API.
Risk: bounded — Locale.US is the standard Netty pattern for protocol-string normalization (see e.g. WebSocketClientHandshaker.java:761).

Sibling fix to #16765, which pinned the same locale gotcha in HttpVersion, RtspMethods, and RtspVersions.

…o Locale.US Two spots in the multipart codec call `String.toLowerCase()` without an explicit Locale to normalize a header value before comparing it to lowercase ASCII constants. The JVM default locale governs that call, and in Turkish (`tr_TR`) the ASCII letter `'I'` lowercases to `'ı'` (U+0131) - so a perfectly valid uppercase form misses the comparison. Concretely on a Turkish-locale JVM: - `HttpPostMultipartRequestDecoder` decoding a part with `Content-Transfer-Encoding: BINARY` (uppercase, RFC 2045 says the mechanism token is case-insensitive) lowercases it to `"bınary"`, fails the equality check against the `binary` / `7bit` / `8bit` constants, and throws `ErrorDataDecoderException: TransferEncoding Unknown: bınary`. - `HttpPostRequestEncoder.finalizeRequest()` skipping a pre-existing `Content-Type: MULTIPART/form-data` header (mixed case, allowed by the Content-Type ABNF) lowercases it to `"multıpart/..."`, misses the prefix check, and the original mixed-case header stays on the request alongside the freshly-built multipart Content-Type. The request goes out with two `Content-Type` headers. Pin both `toLowerCase()` calls to `Locale.US`. The values being compared against are lowercase ASCII tokens and have no business consulting the JVM locale. Tests: - `HttpPostMultiPartRequestDecoderTest .testUppercaseBinaryTransferEncodingUnderTurkishLocale` installs the Turkish locale via `Locale.setDefault(...)` (restored in `finally`) and feeds a multipart body with `Content-Transfer-Encoding: BINARY`. Without the fix it throws; after the fix the file part decodes successfully. - `HttpPostRequestEncoderTest .testFinalizeRemovesPreexistingMultipartContentTypeUnderTurkishLocale` pre-sets `Content-Type: MULTIPART/form-data; boundary=preexisting` on the request, runs the encoder under the Turkish locale, and asserts only one Content-Type header survives - the encoder's own. Without the fix the request ends up with two Content-Type headers. Both tests fail deterministically on the unfixed code (one as an assertion, the other as `TransferEncoding Unknown: bınary`). Sibling fix to netty#16765, which addressed the same locale gotcha in `HttpVersion`, `RtspMethods`, and `RtspVersions`.

netty-project-bot · 2026-05-10T06:17:28Z

Could not create auto-port PR.
Got conflicts when cherry-picking onto 4.1.

netty-project-bot · 2026-05-10T06:17:36Z

Auto-port PR for 5.0: #16782

normanmaurer · 2026-05-10T16:38:15Z

Port for 4.1 #16784

#16784) …o Locale.US (#16768) Two spots in the HTTP multipart codec normalize a header value with `String.toLowerCase()` without an explicit Locale, then compare the result to lowercase ASCII constants. The JVM default Locale governs that call, and on a Turkish (`tr_TR`) JVM the ASCII `'I'` lowercases to `'ı'` (U+0131). A perfectly valid uppercase form silently misses the comparison. Concretely on a Turkish-locale JVM: - `HttpPostMultipartRequestDecoder` decoding a part with `Content-Transfer-Encoding: BINARY` (uppercase, RFC 2045 §6.1 says mechanism tokens are case-insensitive) lowercases the value to `"bınary"`, fails the equality check against the `binary` / `7bit` / `8bit` constants, and throws `ErrorDataDecoderException: TransferEncoding Unknown: bınary`. - `HttpPostRequestEncoder.finalizeRequest()` skipping a pre-existing `Content-Type: MULTIPART/form-data; boundary=...` header (mixed case is allowed by the Content-Type ABNF, RFC 7231 §3.1.1.1) lowercases the value to `"multıpart/..."`, misses the `startsWith("multipart/form-data")` check, and the original mixed-case header survives alongside the freshly-built multipart Content-Type the encoder is about to add. The outgoing request ends up with **two** `Content-Type` headers. The values being compared against are lowercase ASCII tokens and have no business consulting the JVM locale. Pin both `String.toLowerCase()` calls to `Locale.US`: - `codec-http/src/main/java/io/netty/handler/codec/http/multipart/HttpPostMultipartRequestDecoder.java` — `getFileUpload(String delimiter)` lowercases the `Content-Transfer-Encoding` value before matching it against `BIT7` / `BIT8` / `BINARY` mechanism tokens. - `codec-http/src/main/java/io/netty/handler/codec/http/multipart/HttpPostRequestEncoder.java` — `finalizeRequest()` lowercases each existing `Content-Type` before checking if it is the multipart or `application/x-www-form-urlencoded` form (which the encoder is responsible for setting fresh). | Change Point | Test | |--------------|------| | Decoder Content-Transfer-Encoding lowercase under Turkish | `HttpPostMultiPartRequestDecoderTest.testUppercaseBinaryTransferEncodingUnderTurkishLocale` — installs the Turkish locale (restored in `finally`), feeds a multipart body with `Content-Transfer-Encoding: BINARY`, and asserts the file part decodes successfully. Without the fix this throws `TransferEncoding Unknown: bınary`. | | Encoder Content-Type lowercase under Turkish | `HttpPostRequestEncoderTest.testFinalizeRemovesPreexistingMultipartContentTypeUnderTurkishLocale` — pre-sets `Content-Type: MULTIPART/form-data; boundary=preexisting`, runs the encoder under the Turkish locale, and asserts only one Content-Type header survives. Without the fix the request ends up with two Content-Type headers. | Both tests fail deterministically on the unfixed code (one as an assertion failure, the other as a thrown `ErrorDataDecoderException`) and pass after the `Locale.US` change. Verification: ``` mvn -pl codec-http -am test \ -Dtest='HttpPostRequestEncoderTest#testFinalizeRemovesPreexistingMultipartContentTypeUnderTurkishLocale,HttpPostMultiPartRequestDecoderTest#testUppercaseBinaryTransferEncodingUnderTurkishLocale' \ -Dsurefire.failIfNoSpecifiedTests=false ``` - Behavior on en/CJK/most locales: unchanged (the previous default-locale lowercase already produced ASCII). - Behavior on Turkish (and other locales with non-ASCII case mappings): a multipart upload with uppercase `Content-Transfer-Encoding: BINARY` now decodes instead of throwing; an outgoing multipart request with a pre-existing mixed-case `Content-Type: MULTIPART/...` no longer leaks a duplicate Content-Type header. - API: no signature change. All callers continue through the existing public API. - Risk: bounded — `Locale.US` is the standard Netty pattern for protocol-string normalization (see e.g. `WebSocketClientHandshaker.java:761`). Sibling fix to #16765, which pinned the same locale gotcha in `HttpVersion`, `RtspMethods`, and `RtspVersions`. Co-authored-by: Guimu <[email protected]>

… case folding to Locale.US (#16782) Auto-port of #16768 to 5.0 Cherry-picked commit: b9eacea --- ## Problem Two spots in the HTTP multipart codec normalize a header value with `String.toLowerCase()` without an explicit Locale, then compare the result to lowercase ASCII constants. The JVM default Locale governs that call, and on a Turkish (`tr_TR`) JVM the ASCII `'I'` lowercases to `'ı'` (U+0131). A perfectly valid uppercase form silently misses the comparison. Concretely on a Turkish-locale JVM: - `HttpPostMultipartRequestDecoder` decoding a part with `Content-Transfer-Encoding: BINARY` (uppercase, RFC 2045 §6.1 says mechanism tokens are case-insensitive) lowercases the value to `"bınary"`, fails the equality check against the `binary` / `7bit` / `8bit` constants, and throws `ErrorDataDecoderException: TransferEncoding Unknown: bınary`. - `HttpPostRequestEncoder.finalizeRequest()` skipping a pre-existing `Content-Type: MULTIPART/form-data; boundary=...` header (mixed case is allowed by the Content-Type ABNF, RFC 7231 §3.1.1.1) lowercases the value to `"multıpart/..."`, misses the `startsWith("multipart/form-data")` check, and the original mixed-case header survives alongside the freshly-built multipart Content-Type the encoder is about to add. The outgoing request ends up with **two** `Content-Type` headers. The values being compared against are lowercase ASCII tokens and have no business consulting the JVM locale. ## Fix Pin both `String.toLowerCase()` calls to `Locale.US`: - `codec-http/src/main/java/io/netty/handler/codec/http/multipart/HttpPostMultipartRequestDecoder.java` — `getFileUpload(String delimiter)` lowercases the `Content-Transfer-Encoding` value before matching it against `BIT7` / `BIT8` / `BINARY` mechanism tokens. - `codec-http/src/main/java/io/netty/handler/codec/http/multipart/HttpPostRequestEncoder.java` — `finalizeRequest()` lowercases each existing `Content-Type` before checking if it is the multipart or `application/x-www-form-urlencoded` form (which the encoder is responsible for setting fresh). ## Tests | Change Point | Test | |--------------|------| | Decoder Content-Transfer-Encoding lowercase under Turkish | `HttpPostMultiPartRequestDecoderTest.testUppercaseBinaryTransferEncodingUnderTurkishLocale` — installs the Turkish locale (restored in `finally`), feeds a multipart body with `Content-Transfer-Encoding: BINARY`, and asserts the file part decodes successfully. Without the fix this throws `TransferEncoding Unknown: bınary`. | | Encoder Content-Type lowercase under Turkish | `HttpPostRequestEncoderTest.testFinalizeRemovesPreexistingMultipartContentTypeUnderTurkishLocale` — pre-sets `Content-Type: MULTIPART/form-data; boundary=preexisting`, runs the encoder under the Turkish locale, and asserts only one Content-Type header survives. Without the fix the request ends up with two Content-Type headers. | Both tests fail deterministically on the unfixed code (one as an assertion failure, the other as a thrown `ErrorDataDecoderException`) and pass after the `Locale.US` change. Verification: ``` mvn -pl codec-http -am test \ -Dtest='HttpPostRequestEncoderTest#testFinalizeRemovesPreexistingMultipartContentTypeUnderTurkishLocale,HttpPostMultiPartRequestDecoderTest#testUppercaseBinaryTransferEncodingUnderTurkishLocale' \ -Dsurefire.failIfNoSpecifiedTests=false # Tests run: 2, Failures: 0, Errors: 0, Skipped: 0 ``` ## Impact - Behavior on en/CJK/most locales: unchanged (the previous default-locale lowercase already produced ASCII). - Behavior on Turkish (and other locales with non-ASCII case mappings): a multipart upload with uppercase `Content-Transfer-Encoding: BINARY` now decodes instead of throwing; an outgoing multipart request with a pre-existing mixed-case `Content-Type: MULTIPART/...` no longer leaks a duplicate Content-Type header. - API: no signature change. All callers continue through the existing public API. - Risk: bounded — `Locale.US` is the standard Netty pattern for protocol-string normalization (see e.g. `WebSocketClientHandshaker.java:761`). Sibling fix to #16765, which pinned the same locale gotcha in `HttpVersion`, `RtspMethods`, and `RtspVersions`. Co-authored-by: Guimu <[email protected]> Co-authored-by: Norman Maurer <[email protected]>

daguimu force-pushed the fix/http-multipart-locale-us branch from 0c94613 to 0da3f84 Compare May 8, 2026 02:30

normanmaurer reviewed May 8, 2026

View reviewed changes

Comment thread codec-http/src/test/java/io/netty/handler/codec/http/multipart/HttpPostRequestEncoderTest.java Outdated

Apply suggestion from @normanmaurer

264677d

normanmaurer approved these changes May 8, 2026

View reviewed changes

normanmaurer added needs-cherry-pick-4.1 This PR should be cherry-picked to 4.1 once merged. needs-cherry-pick-5.0 This PR should be cherry-picked to 5.0 once merged. labels May 10, 2026

normanmaurer added this to the 4.2.14.Final milestone May 10, 2026

normanmaurer merged commit b9eacea into netty:4.2 May 10, 2026
23 checks passed

github-actions Bot removed the needs-cherry-pick-5.0 This PR should be cherry-picked to 5.0 once merged. label May 10, 2026

netty-project-bot mentioned this pull request May 10, 2026

Auto-port 5.0: Pin multipart Content-Type / Content-Transfer-Encoding case folding to Locale.US #16782

Merged

normanmaurer mentioned this pull request May 10, 2026

Pin multipart Content-Type / Content-Transfer-Encoding case folding t… #16784

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Pin multipart Content-Type / Content-Transfer-Encoding case folding to Locale.US#16768

Pin multipart Content-Type / Content-Transfer-Encoding case folding to Locale.US#16768
normanmaurer merged 2 commits into
netty:4.2from
daguimu:fix/http-multipart-locale-us

daguimu commented May 8, 2026

Uh oh!

Uh oh!

Uh oh!

netty-project-bot commented May 10, 2026

Uh oh!

netty-project-bot commented May 10, 2026

Uh oh!

normanmaurer commented May 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

daguimu commented May 8, 2026

Problem

Fix

Tests

Impact

Uh oh!

Uh oh!

Uh oh!

netty-project-bot commented May 10, 2026

Uh oh!

netty-project-bot commented May 10, 2026

Uh oh!

normanmaurer commented May 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants