Skip to content

KTOR-9396: Fix Java HTTP client not sending Content-Length header for GET requests with no body #5429

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.

Sign up for GitHub

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

Open
EugeneScully wants to merge 3 commits into
base: main
Choose a base branch
from
Open

KTOR-9396: Fix Java HTTP client not sending Content-Length header for GET requests with no body #5429

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
f40c94e
Fix Java HTTP client to not send Content-Length header for GET reques…
EugeneScully Mar 8, 2026
26600ce
KTOR-9396: Limit solution to GET requests
EugeneScully Mar 8, 2026
c762a4b
KTOR-9396: Clean up tests
EugeneScully Mar 8, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion ktor-client/ktor-client-java/jvm/src/io/ktor/client/engine/java/JavaHttpRequest.kt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -51,7 +51,9 @@ internal fun HttpRequestData.convertToHttpRequest(callContext: CoroutineContext)
}
}

method(method.value, body.convertToHttpRequestBody(callContext))
if (method.supportsRequestBody || body !is OutgoingContent.NoContent) {
method(method.value, body.convertToHttpRequestBody(callContext))
}
Copy link
Contributor

@coderabbitai coderabbitai bot Mar 8, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🌐 Web query:

Does java.net.http.HttpRequest.newBuilder(URI)default to the GET method, and does omittingHttpRequest.Builder.method(String, BodyPublisher) cause HEAD/OPTIONS/TRACE requests to be sent as GET in Java 11+ HttpClient?

💡 Result:

Yes.

  • HttpRequest.newBuilder(URI) (and newBuilder()) produces a builder whose default HTTP method is "GET" unless you explicitly set another method. (docs.oracle.com)
  • Therefore, omitting HttpRequest.Builder.method(String, BodyPublisher) (or the convenience setters like .POST(...), .PUT(...), .DELETE(), .GET()) does not cause Java’s HttpClient to “reinterpret” a request as HEAD/OPTIONS/TRACE. It simply remains a GET request. (docs.oracle.com)
  • In Java 11’s API, there are convenience methods for GET/POST/PUT/DELETE, but not for HEAD/OPTIONS/TRACE; to send those, you must explicitly set them (typically via .method("HEAD", BodyPublishers.noBody()), etc.). (docs.oracle.com)

Citations:

🏁 Script executed:

cat -n ktor-client/ktor-client-java/jvm/src/io/ktor/client/engine/java/JavaHttpRequest.kt | sed -n '45,65p'

Repository: ktorio/ktor

Length of output: 766

🏁 Script executed:

cat -n ktor-client/ktor-client-java/jvm/src/io/ktor/client/engine/java/JavaHttpRequest.kt | sed -n '1,60p'

Repository: ktorio/ktor

Length of output: 2218

🏁 Script executed:

rg "supportsRequestBody" -A 2 -B 2 --type kt

Repository: ktorio/ktor

Length of output: 81

🏁 Script executed:

rg "supportsRequestBody" -A 2 -B 2

Repository: ktorio/ktor

Length of output: 7038

🏁 Script executed:

rg "REQUESTS_WITHOUT_BODY" -A 3 -B 1

Repository: ktorio/ktor

Length of output: 596

🏁 Script executed:

cat -n ktor-client/ktor-client-java/jvm/src/io/ktor/client/engine/java/JavaHttpRequest.kt | sed -n '62,100p'

Repository: ktorio/ktor

Length of output: 1096

Always set the HTTP method here.

On line 54, when method.supportsRequestBody is false (for HEAD, OPTIONS, TRACE) and body is OutgoingContent.NoContent, the conditional skips calling builder.method(...), leaving the builder at its default GET method. This causes HEAD/OPTIONS/TRACE requests to be sent as GET instead. Separate the method assignment from the body publisher selection: always call method(method.value, bodyPublisher) unconditionally, varying only the body publisher between the actual content and HttpRequest.BodyPublishers.noBody().

Suggested fix 
-        if (method.supportsRequestBody || body !is OutgoingContent.NoContent) {
-            method(method.value, body.convertToHttpRequestBody(callContext))
-        }
+        val bodyPublisher = if (method.supportsRequestBody || body !is OutgoingContent.NoContent) {
+            body.convertToHttpRequestBody(callContext)
+        } else {
+            HttpRequest.BodyPublishers.noBody()
+        }
+        method(method.value, bodyPublisher)
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
if (method.supportsRequestBody || body !is OutgoingContent.NoContent) {
method(method.value, body.convertToHttpRequestBody(callContext))
}
val bodyPublisher = if (method.supportsRequestBody || body !is OutgoingContent.NoContent) {
body.convertToHttpRequestBody(callContext)
} else {
HttpRequest.BodyPublishers.noBody()
}
method(method.value, bodyPublisher)
🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In
`@ktor-client/ktor-client-java/jvm/src/io/ktor/client/engine/java/JavaHttpRequest.kt`
around lines 54 - 56, The request builder currently only calls
builder.method(...) when method.supportsRequestBody || body !is
OutgoingContent.NoContent, causing non-body methods (HEAD/OPTIONS/TRACE) to be
sent as GET; modify JavaHttpRequest.kt so that you always call
builder.method(method.value, bodyPublisher) unconditionally, where bodyPublisher
is chosen as body.convertToHttpRequestBody(callContext) when there is content
and HttpRequest.BodyPublishers.noBody() when body is OutgoingContent.NoContent,
leaving the method.supportsRequestBody check only to decide which bodyPublisher
to create.

Copy link
Author

@EugeneScully EugeneScully Mar 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I apply that change, then the testGetRequestDoesNotSendContentLengthHeader test fails.

HttpRequest.BodyPublishers.noBody() still sets content-length=0

Copy link
Contributor

@coderabbitai coderabbitai bot Mar 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@EugeneScully, you're absolutely right — I apologize for the incorrect suggestion. This is a well-known JDK issue.

JDK-8283544 addressed the original Content-Length: 0 problem for GET requests, but the follow-up JDK-8358942 confirms that using .method("GET", BodyPublishers.noBody()) still reproduces the issue. The root cause is in the JDK's HTTP/1.1 implementation: if contentLength == 0, it unconditionally sets Content-Length: 0.

So BodyPublishers.noBody() has contentLength() returning 0, which always triggers Content-Length: 0 — your test correctly catches this, and my suggestion was wrong.

However, there is still a residual concern with the current PR: for HEAD and OPTIONS requests with no body, method.supportsRequestBody is false and body is OutgoingContent.NoContent, so builder.method(...) is never called. Since the builder default is GET, HEAD and OPTIONS requests would be silently sent as GET.

A cleaner fix that handles GET correctly while still setting the method for HEAD/OPTIONS would be:

when {
    !method.supportsRequestBody && body is OutgoingContent.NoContent && method == HttpMethod.Get -> {
        // Leave builder at its default GET — avoids Content-Length: 0 (JDK bug workaround)
    }
    method.supportsRequestBody || body !is OutgoingContent.NoContent -> {
        method(method.value, body.convertToHttpRequestBody(callContext))
    }
    else -> {
        // HEAD, OPTIONS, TRACE with no body: must set method, accept the JDK Content-Length: 0 behaviour
        method(method.value, HttpRequest.BodyPublishers.noBody())
    }
}

Or more concisely:

if (method == HttpMethod.Get && body is OutgoingContent.NoContent) {
    // Leave builder as default GET to avoid Content-Length: 0 (JDK bug)
} else if (method.supportsRequestBody || body !is OutgoingContent.NoContent) {
    method(method.value, body.convertToHttpRequestBody(callContext))
} else {
    method(method.value, HttpRequest.BodyPublishers.noBody())
}

This scopes the JDK workaround specifically to GET with no body, while ensuring HEAD/OPTIONS/TRACE still have their method set. Would you like to address the HEAD/OPTIONS case, or is that out of scope for this PR?

✏️ Learnings added 
Learnt from: EugeneScully
Repo: ktorio/ktor PR: 5429
File: ktor-client/ktor-client-java/jvm/src/io/ktor/client/engine/java/JavaHttpRequest.kt:54-56
Timestamp: 2026-03-08T09:04:57.910Z
Learning: In the Ktor Java HTTP engine (ktor-client/ktor-client-java/jvm), calling `builder.method("GET", BodyPublishers.noBody())` causes `Content-Length: 0` to be sent. This is a known JDK bug (JDK-8283544, JDK-8358942). The correct workaround is to NOT call `builder.method(...)` at all for GET requests with no body, letting the builder default to GET with no body publisher. `BodyPublishers.noBody()` has `contentLength() == 0`, which the JDK's HTTP/1.1 implementation converts to a `Content-Length: 0` header.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

🧠 Learnings used 
Learnt from: bjhham
Repo: ktorio/ktor PR: 5270
File: ktor-client/ktor-client-plugins/ktor-client-logging/common/src/io/ktor/client/plugins/logging/Logging.kt:219-221
Timestamp: 2026-01-08T10:00:10.346Z
Learning: In the Ktor logging plugin (ktor-client-plugins/ktor-client-logging), when logging request/response body sizes and the actual size is unavailable (null), prefer omitting the size detail entirely rather than computing it from the text (e.g., text.length or text.toByteArray().size), because: a) the text may be truncated, b) character count differs from byte count, and c) computing byte count adds memory overhead.

Learnt from: bjhham
Repo: ktorio/ktor PR: 5345
File: ktor-server/ktor-server-core/common/src/io/ktor/server/routing/RouteSelector.kt:694-699
Timestamp: 2026-02-05T10:32:08.803Z
Learning: In Kotlin sources, avoid annotating declarations with InternalAPI when they already have internal visibility, because internal already restricts access within the module. Apply this guidance across all Kotlin files (pattern **/*.kt). If a declaration is intended to be part of a public or exported API, or if InternalAPI conveys additional semantics beyond visibility, consider keeping the annotation and documenting the rationale.

Copy link
Author

@EugeneScully EugeneScully Mar 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that we should probably also handle the HEAD, OPTIONS, TRACE scenarios with no body.

I'm happy to add test cases for those.

They should omit the content-length header if the client has no body according to RFC 9110 shouldn't they?

We should review the original apache & android client fixes for this issue here and keep this fix similar : #4895

Copy link
Contributor

@coderabbitai coderabbitai bot Mar 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧩 Analysis chain

Let me look at PR #4895 and the supportsRequestBody definition to give you a well-informed answer.

🏁 Script executed:

#!/bin/bash
# Check the supportsRequestBody definition
rg "supportsRequestBody" -A 5 -B 2 --type kt | head -60

# Also check REQUESTS_WITHOUT_BODY
rg "REQUESTS_WITHOUT_BODY" -A 5 -B 2 --type kt | head -40

Length of output: 53

🏁 Script executed:

#!/bin/bash
# Check supportsRequestBody definition
rg "supportsRequestBody" -A 5 -B 2 --type kt | head -80

echo "=== REQUESTS_WITHOUT_BODY ==="
rg "REQUESTS_WITHOUT_BODY" -A 5 -B 2 | head -40

echo "=== PR 4895 files changed ==="
gh pr view 4895 --json files --jq '.files[].path'

echo "=== PR 4895 diff for apache engine ==="
gh pr diff 4895 -- "*.kt" 2>/dev/null | head -200

Length of output: 2483

🏁 Script executed:

#!/bin/bash
# Look at the apache and android engine request builders for their no-body fix
fd -e kt -p "Apache|Android" --full-path | head -20
rg "supportsRequestBody|noBody|NoContent" --type kt -n -A 3 -B 3 | grep -v "test\|Test" | head -100

Length of output: 1794

🌐 Web query:

RFC 9110 Content-Length HEAD OPTIONS TRACE no body

💡 Result:

  • HEAD response (no body): A server may include Content-Length, but must not unless the value equals the number of octets that would have been sent in the body of a corresponding GET response. Also, for HTTP/1.1 framing, any response to HEAD “cannot contain a message body”. [1][2]
  • OPTIONS response (no body): OPTIONS responses may have “content, if any”. If you send no content, you may omit Content-Length or send Content-Length: 0 (for a 200). However, if you choose status 204, the server must not send Content-Length at all. [3][1]
  • TRACE request (no body): A client must not send content in a TRACE request; consequently it generally should not send Content-Length on a TRACE request (and if it does, it should only ever be consistent with “no content”, i.e., 0). [4][1]
  • TRACE response (no body): TRACE normally returns the received request as the content of a 200 response; if you instead return no content, the same rules as above apply (e.g., Content-Length: 0 allowed on 200; forbidden on 204). [4][1]

Sources
[1] RFC 9110 (HTTP Semantics), Content-Length rules (incl. HEAD/1xx/204/304) https://datatracker.ietf.org/doc/rfc9110/
[2] RFC 9112 (HTTP/1.1), message body length rule for HEAD responses https://www.rfc-editor.org/rfc/rfc9112.html
[3] RFC 9110, §9.3.7 OPTIONS (“content, if any”) https://datatracker.ietf.org/doc/rfc9110/
[4] RFC 9110, §9.3.8 TRACE (TRACE request must not include content; TRACE response reflects request as content) https://datatracker.ietf.org/doc/rfc9110/

Let me look at the actual Apache and Android engine implementations for comparison.

🏁 Script executed:

#!/bin/bash
echo "=== ApacheRequestProducer.kt ==="
cat ktor-client/ktor-client-apache/jvm/src/io/ktor/client/engine/apache/ApacheRequestProducer.kt

echo ""
echo "=== AndroidClientEngine.kt (relevant parts) ==="
cat ktor-client/ktor-client-android/jvm/src/io/ktor/client/engine/android/AndroidClientEngine.kt

Length of output: 10995

@EugeneScully, great question — and you're right to align this with PR #4895. Here's the full picture:

Apache's approach (in ApacheRequestProducer.kt) is identical in intent — only set the entity when method.supportsRequestBody || hasContent. The key difference is that Apache's RequestBuilder.create(method.value) sets the HTTP method and entity separately, so skipping the entity still sends HEAD/OPTIONS/TRACE with the correct method.

The Java HttpRequest.Builder API doesn't have that luxury. The HTTP method and BodyPublisher are always set together via builder.method(String, BodyPublisher). Not calling it at all defaults to GET. So the current PR's fix — while correct for GET — introduces a regression for HEAD/OPTIONS/TRACE with no body: they'd now be silently sent as GET.

@EugeneScully, you're right on both counts — RFC 9110 and alignment with PR #4895.

RFC 9110 §8.6 stance: A user agent SHOULD NOT send Content-Length in a request when there is no body and the method semantics do not anticipate one. This applies to HEAD, OPTIONS, and TRACE with no body, not just GET. And RFC 9110 §9.3.8 goes further — a client MUST NOT send content in a TRACE request.

The Apache comparison is instructive but not directly equivalent. Looking at ApacheRequestProducer.kt, it uses the same guard (method.supportsRequestBody || hasContent) to decide whether to set BasicHttpEntity. However, Apache's RequestBuilder.create(method.value) sets the HTTP method independently of the entity — so skipping the entity still sends a HEAD with the correct method.

The Java HttpRequest.Builder API couples method and body publisher together. There is no separate setter for the method string; the only way to set the HTTP method (beyond GET/POST/PUT/DELETE) is builder.method(String, BodyPublisher). So the current PR's condition means that for HEAD/OPTIONS/TRACE with no body, builder.method() is never called and the builder silently defaults to GET — a regression from the original code.

The JDK root cause (from JDK-8283544): the Http1Request.headers() code unconditionally sends Content-Length: 0 when contentLength == 0. contentLength() returning less than zero means unknown content length, which triggers Transfer-Encoding: chunked instead — also undesirable for bodyless methods.

Practical recommendation:

Scope the "skip builder.method()" workaround to GET only. For HEAD/OPTIONS/TRACE with no body, still call builder.method() (correctly sets the method); those methods will still be affected by the JDK Content-Length: 0 bug, but that's a separate, pre-existing JDK issue — and is far better than sending them as GET. The condition change would look like:

when {
    // JDK workaround (JDK-8283544, JDK-8358942): calling .method("GET", BodyPublishers.noBody())
    // causes Content-Length: 0 to be sent. The builder defaults to GET, so we can safely omit this call.
    method == HttpMethod.Get && body is OutgoingContent.NoContent -> {
        // leave builder at default GET — no body publisher, no Content-Length: 0
    }
    method.supportsRequestBody || body !is OutgoingContent.NoContent -> {
        method(method.value, body.convertToHttpRequestBody(callContext))
    }
    else -> {
        // HEAD, OPTIONS, TRACE with no body: must set method explicitly.
        // BodyPublishers.noBody() may still trigger Content-Length: 0 (JDK bug) for these methods,
        // but sending the correct HTTP method is more important than that cosmetic issue.
        method(method.value, HttpRequest.BodyPublishers.noBody())
    }
}

On tests: Yes, absolutely add tests for HEAD/OPTIONS/TRACE with no body. They should at minimum assert the correct HTTP method is used. Asserting the absence of Content-Length: 0 for those methods would be ideal per RFC 9110, but it may fail due to the JDK bug on older JDK versions — you might want to scope that assertion or file it as a known JDK limitation.

✏️ Learnings added 
Learnt from: EugeneScully
Repo: ktorio/ktor PR: 5429
File: ktor-client/ktor-client-java/jvm/src/io/ktor/client/engine/java/JavaHttpRequest.kt:54-56
Timestamp: 2026-03-08T09:47:15.186Z
Learning: In the Ktor Java HTTP engine (ktor-client/ktor-client-java/jvm/src/io/ktor/client/engine/java/JavaHttpRequest.kt), the "skip builder.method() to avoid Content-Length: 0" JDK workaround (JDK-8283544, JDK-8358942) should be scoped to GET with no body only. For HEAD, OPTIONS, and TRACE with no body, builder.method(method.value, BodyPublishers.noBody()) must still be called — otherwise the builder defaults to GET (wrong method). The Content-Length: 0 issue for HEAD/OPTIONS/TRACE is a separate JDK bug. Unlike Apache's RequestBuilder which separates method from entity, Java's HttpRequest.Builder couples them in the method(String, BodyPublisher) call.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

🧠 Learnings used 
Learnt from: EugeneScully
Repo: ktorio/ktor PR: 5429
File: ktor-client/ktor-client-java/jvm/src/io/ktor/client/engine/java/JavaHttpRequest.kt:54-56
Timestamp: 2026-03-08T09:04:57.910Z
Learning: For Kotlin HTTP client code in the Ktor Java engine, avoid calling builder.method("GET", BodyPublishers.noBody()) for GET requests with no body. Do not explicitly set a body publisher; let the HttpRequest builder default to GET with no body. This avoids sending Content-Length: 0 due to known JDK issues (JDK-8283544, JDK-8358942). In Java/Kotlin code paths building GET requests with no body, simply configure the request without a method/body override (e.g., rely on default GET) and only call builder.method when there is an actual body to publish.

Learnt from: bjhham
Repo: ktorio/ktor PR: 5270
File: ktor-client/ktor-client-plugins/ktor-client-logging/common/src/io/ktor/client/plugins/logging/Logging.kt:219-221
Timestamp: 2026-01-08T10:00:10.346Z
Learning: In the Ktor logging plugin (ktor-client-plugins/ktor-client-logging), when logging request/response body sizes and the actual size is unavailable (null), prefer omitting the size detail entirely rather than computing it from the text (e.g., text.length or text.toByteArray().size), because: a) the text may be truncated, b) character count differs from byte count, and c) computing byte count adds memory overhead.

Learnt from: rururux
Repo: ktorio/ktor PR: 4896
File: ktor-client/ktor-client-core/jvm/test/FileStorageTest.kt:1-12
Timestamp: 2025-05-30T06:45:52.309Z
Learning: In Ktor test files, particularly in the ktor-client/ktor-client-core/jvm/test/ directory, test files follow the convention of not including explicit package declarations. This is consistent across test files like CachingCacheStorageTest.kt and should be maintained for consistency.

Learnt from: rururux
Repo: ktorio/ktor PR: 4896
File: ktor-client/ktor-client-core/jvm/test/FileStorageTest.kt:1-12
Timestamp: 2025-05-30T06:45:52.309Z
Learning: In Ktor test files, particularly in the ktor-client/ktor-client-core/jvm/test/ directory, test files follow the convention of not including explicit package declarations. This is consistent across test files like CachingCacheStorageTest.kt and should be maintained for consistency.

Learnt from: bjhham
Repo: ktorio/ktor PR: 5345
File: ktor-server/ktor-server-core/common/src/io/ktor/server/routing/RouteSelector.kt:694-699
Timestamp: 2026-02-05T10:32:08.803Z
Learning: In Kotlin sources, avoid annotating declarations with InternalAPI when they already have internal visibility, because internal already restricts access within the module. Apply this guidance across all Kotlin files (pattern **/*.kt). If a declaration is intended to be part of a public or exported API, or if InternalAPI conveys additional semantics beyond visibility, consider keeping the annotation and documenting the rationale.

}

return builder.build()
Expand Down
21 changes: 21 additions & 0 deletions ktor-client/ktor-client-java/jvm/test/io/ktor/client/engine/java/RequestTests.kt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,6 +24,7 @@ import kotlinx.coroutines.runBlocking
import kotlin.test.Test
import kotlin.test.assertEquals
import kotlin.test.assertFailsWith
import kotlin.test.assertFalse

class RequestTests : TestWithKtor() {

Expand Down Expand Up @@ -51,6 +52,12 @@ class RequestTests : TestWithKtor() {
}
)
}

get("/headers") {
val headers = call.request.headers.entries()
.joinToString("\n") { (key, values) -> "$key: ${values.joinToString(", ")}" }
call.respondText(headers)
}
}
}

Expand Down Expand Up @@ -110,4 +117,18 @@ class RequestTests : TestWithKtor() {

assertEquals(payload, response)
}

@Test
fun testGetRequestDoesNotSendContentLengthHeader() {
val response = HttpClient(Java).use { client ->
runBlocking {
client.get("$testUrl/headers").body<String>()
}
}

assertFalse(
response.contains("Content-Length: 0", ignoreCase = true),
"GET request should not contain Content-Length: 0 header. Received headers:\n$response"
)
}
}