Changelog 3.5 version

3.5.2

released 4th August 2026

Client

SSE client (CIO engine) sends spurious `Content-Length: 0` on body-less GET (RFC 9110 § 8.6 violation; rejected by AWS ELB)

https://youtrack.jetbrains.com/issue/KTOR-9588

Summary

HttpClient(CIO).sseSession(url) / HttpClient(CIO).sse(url) emit a Content-Length: 0 request header on the outgoing GET, even though there is no request body and GET semantics do not anticipate one. This violates RFC 9110 § 8.6 ("A user agent SHOULD NOT send a Content-Length header field when the request message does not contain content and the method semantics do not anticipate such content"), and causes strict reverse proxies — notably AWS ELB — to reject the request with 400 Bad Request (treating it as a request-smuggling smell per RFC 9110 § 9.3.1).

curl, java.net.http.HttpClient via HttpRequest.Builder.GET(), browsers, and python-requests all omit the header in the same situation. Ktor CIO is the outlier.

Scope: which engine is broken

The defect is observable on the wire only with the CIO engine.

Engine	Wire behavior on body-less SSE GET	Source-level state
CIO	Writes `Content-Length: 0` to the wire	Buggy: `hasContent = body !is OutgoingContent.NoContent` doesn't unwrap `ContentWrapper`, so the SSE plugin's `SSEClientContent` makes `hasContent = true` and the explicit `headerLine(ContentLength, …)` fires.
Java	Does not write `Content-Length` to the wire on JDK 21 (HTTP/1.1 and HTTP/2)	Source path is correct in practice: `Content-Length` is in `DISALLOWED_HEADERS` so it's stripped, and `convertToHttpRequestBody` recurses through `ContentWrapper` to `NoContent` → `BodyPublishers.noBody()`. The wire result then depends on JDK behavior for `noBody()`, which is currently to omit the header.

So the production fix lives in CIO. The Java engine is incidentally correct because Ktor delegates the body-shape decision to the JDK and the JDK behaves correctly. A defensive change on the Java engine to also explicitly recognize wrapped NoContent would not change observable wire behavior on supported JDKs, but would lock in correctness independent of JDK / ALPN changes.

Affected versions

Confirmed reproducing in Ktor 3.1.3 and Ktor 3.4.2 (latest stable at time of filing). Source on main is still affected (utils.kt hasContent check is unchanged).

Reproduction

Any body-less SSE GET via the CIO engine against a server fronted by AWS ELB will reproduce. Minimal:

import io.ktor.client.HttpClient
import io.ktor.client.engine.cio.CIO
import io.ktor.client.plugins.sse.SSE
import io.ktor.client.plugins.sse.sseSession

val client = HttpClient(CIO) { install(SSE) }
client.sseSession("https://<aws-elb-fronted-host>/some/path")

The outgoing wire request includes:

GET /some/path HTTP/1.1
Host: <aws-elb-fronted-host>
Accept: text/event-stream
Cache-Control: no-store
Content-Length: 0          ← should not be here

and AWS ELB responds:

HTTP/1.1 400 Bad Request
Server: awselb/2.0
Content-Type: text/html
Content-Length: 122

— the request never reaches the origin application. Removing Content-Length: 0 (e.g., via curl with the same headers) makes the same path return the origin's expected response.

Empirical diff that isolates the trigger (real example, Figma's MCP server):

Headers	Response
`Accept`, `Authorization`, `Accept-Charset` (no Content-Length)	`404` from origin
same + `Content-Length: 0`	`400 Bad Request` from `awselb/2.0`

Expected behavior

Content-Length should not appear on a body-less GET request, in line with RFC 9110 § 8.6.

Actual behavior

On CIO: Content-Length: 0 is emitted on the wire and AWS ELB returns 400 Bad Request before the request reaches the origin server.

Root cause

Three points conspire (verified against Ktor 3.4.2 sources):

ktor-client-core/common/src/io/ktor/client/utils/Content.kt — EmptyContent, the default outgoing body when none is set, overrides contentLength: Long = 0 (not null). This primes a downstream Content-Length value of 0 for any request that does not call setBody.
ktor-client-core/common/src/io/ktor/client/plugins/sse/SSEClientContent.kt — the SSE plugin wraps the request body in SSEClientContent, which extends OutgoingContent.ContentWrapper, not OutgoingContent.NoContent. Engines that check "is this body-less?" via body !is NoContent therefore get the wrong answer for SSE GETs, even though the wrapped body is in fact EmptyContent (a NoContent).
CIO engine writes Content-Length explicitly — ktor-client-cio/common/src/io/ktor/client/engine/cio/utils.kt, writeHeaders:
```
val hasContent = body !is OutgoingContent.NoContent       // TRUE for SSEClientContent
if (contentLength != null) {
    if (method.supportsRequestBody || hasContent) {
        builder.headerLine(HttpHeaders.ContentLength, contentLength)   // writes "Content-Length: 0"
    }
}
```
SSEClientContent is a ContentWrapper, not NoContent, so hasContent = true. The guard fires and Content-Length is written. The check should unwrap ContentWrapper (e.g. body.getUnwrapped() !is NoContent); note writeBody already does body.getUnwrapped() further down, so the engine is internally inconsistent.

The Java engine reaches a correct outcome through a different path (described in the Scope section above) and is currently not observed to fail on the wire.

Spec references

RFC 9110 § 8.6 (Content-Length) — SHOULD NOT send Content-Length when there is no content and the method does not anticipate it. https://www.rfc-editor.org/rfc/rfc9110#section-8.6
RFC 9110 § 9.3.1 (GET semantics) — "Content received in a GET request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack." https://www.rfc-editor.org/rfc/rfc9110#section-9.3.1

Suggested fix

In order of preference:

Fix at the SSE plugin layer (single, surgical change) — make SSEClientContent extend OutgoingContent.NoContent when the wrapped body is NoContent. Engines' existing is NoContent checks then fire correctly. No engine code needs to change. (Possible API/inheritance constraints — see if ContentWrapper allows this; if not, fall back to fix 2.)
Fix in the CIO engine — change hasContent = body !is OutgoingContent.NoContent to unwrap ContentWrapper (body.getUnwrapped() !is NoContent or equivalent). Required.
(Optional, defensive) — apply the same unwrap-aware check in the Java engine so that a future JDK change cannot regress wire behavior.

A regression test should assert the wire-level absence of Content-Length on the outgoing GET of client.sseSession("…"), running against at least CIO (and ideally Java) engines. Use ktor-test-server (or equivalent) to capture raw request headers rather than asserting against Ktor's internal request model — the bug is at the engine output, not in Ktor's request representation.

EmptyContent.contentLength = 0 itself should not be changed to null — that has a much wider blast radius and would alter behavior for every other request type. The fix should be localized to SSE / NoContent recognition.

Linked PR

Proposed fix in #5620.

Real-world impact

Breaks any Ktor-based client built on the CIO engine when it tries to open an SSE stream against any server fronted by AWS ELB with default request-smuggling protections. Specifically, the official Kotlin MCP SDK (io.modelcontextprotocol:kotlin-sdk:0.7.7) opens an SSE GET via StreamableHttpClientTransport after notifications/initialized; with HttpClient { … } (default engine = CIO), it fails against https://mcp.figma.com/mcp/<client_id> with SSEClientException: Expected status code 200 but was 400, where the 400 originates from awselb/2.0. Switching the user-side HttpClient to the Java engine works around the issue, confirming that the CIO engine is the only path exhibiting the wire-level defect.

Acceptance criteria

HttpClient(CIO).sseSession("…") against a body-less GET produces an outgoing request with no Content-Length header on the wire.
A regression test enforces the above against the CIO engine (and, ideally, the Java engine too as a defensive parity).
Non-GET SSE requests (where the spec permits a body) still emit Content-Length correctly when there is a real body.

SaveBody performance regression

Darwin: Semicolons in URL path are sanitized

Core

ByteReadChannel.readLine corrupts multi-byte UTF-8 by splitting a character at a buffer boundary

Inefficient text reading function in DefaultTransform

Update kotlinx-io to 0.9.1

IO

ByteReadChannel.readLineTo: Return read bytes count instead of decoded characters count

ByteReadChannel.readLineStrict: Misleading definition of limit parameter in KDocs

UTF-8 encoding in ktor-io bypasses JVM String.getBytes intrinsics, slowing every text response by 5-7x

https://youtrack.jetbrains.com/issue/KTOR-9704

Summary:

On the JVM, encodeToByteArray(throwOnInvalidSequence = true) is a char-by-char Kotlin loop. It cannot use String.getBytes(UTF_8), which is backed by intrinsic-accelerated code (JEP 254); an ASCII string already stores its bytes in UTF-8-compatible form, so getBytes reduces to a SIMD hasNegatives scan plus an array copy.

Project: Ktor (KTOR)
Type: Performance Problem
Subsystems: Core, ktor-io
Affected versions: 3.x

Where it happens

every server response produced by ContentNegotiation with kotlinx-serialization or Gson (both emit TextContent), and with Jackson when configured with streamBody = false (the default streamBody = true writes bytes directly via Jackson's UTF8JsonGenerator and is not affected),
every call.respondText(...),
JVM client request bodies sent as TextContent,
any other String.toByteArray() caller in ktor.

The cost scales linearly with response size and is paid once per response.

Proposed fix 1 (semantics-preserving)

The current UTF-8 branch throws CharacterCodingException on unpaired surrogates, so raw getBytes (which substitutes ?) is not a drop-in replacement. Instead:

Scan the string once, validating surrogate pairing (a valid pair, e.g. an emoji, is skipped as a unit).
If the string is well-formed, use String.getBytes(UTF_8): for well-formed input it produces byte-identical output to the validating encoder.
If an unpaired surrogate is found, delegate to the existing validating encoder, which throws exactly as before.

Proposed fix 2 : adopt replacement semantics and drop the scan

Using String.getBytes(UTF_8) directly, with no validation scan, gives the full intrinsic speed: 2.3 µs instead of 29.6 µs at 100 KB (87x over current). The** behavioral difference** is that a string containing an unpaired surrogate encodes it as ? instead of throwing CharacterCodingException.

Solution comparison

	Current	Solution 1: scan + `getBytes`	Solution 2: `getBytes` only (alternate)
960 B JSON	1,909 ns	385 ns (5.0x)	28 ns (69x)
16 KB JSON	32,237 ns	5,090 ns (6.3x)	737 ns (44x)
100 KB JSON	197,189 ns	29,591 ns (6.7x)	2,270 ns (87x)
16 KB with emoji	33,223 ns	13,380 ns (2.5x)	11,192 ns (3.0x)
Allocation	2.1x payload	1.0x (exact)	1.0x (exact)
Unpaired surrogate	throws	throws (identical)	replaces with `?`

Network

Sockets: Canceling a SelectorManager job doesn't close it properly

https://youtrack.jetbrains.com/issue/KTOR-9683

      val address = coroutineScope {
			val manager = CompletableDeferred<SelectorManager>()
			val managerJob = launch(Dispatchers.Default + CoroutineName("FindMongoAddressManager")) {
				SelectorManager(currentCoroutineContext())
					.also { manager.complete(it) }
			}

			val hostName = "localhost"

			println("  Searching for the address of the running MongoDB instance…")
			val address = InetSocketAddress(hostName, 27017)

			try {
				println("» Trying $address…")
				aSocket(manager.await()).tcp().connect(address.hostname, address.port) {
					socketTimeout = 100
				}.use {
					println("  Connected successfully!")
				}
				// manager.await().close()  // HERE
				managerJob.cancel("We found a valid address.")
				println("  Closed the socket.")
				return@coroutineScope address
			} catch (e: Exception) {
				println("  Could not connect to MongoDB on socket $address • $e")
			}

			error("Could not find on which port MongoDB is running.")
			// No need to cancel the manager, it will be killed by the exception
		}

		println("Found address: $address")

You will need something listening on localhost:27017.

If the manager.await().close() is added, the code runs correctly: the socket connects, disconnects, and the code prints localhost:27017 after all coroutines are finished.

However, if the line is commented out, four coroutines are left hanging:

Coroutine "coroutine#76":BlockingCoroutine{Active}@3390c044, state: SUSPENDED

Coroutine TestScope[test started], state: RUNNING

Coroutine "kotlinx.coroutines.test runner#77":StandaloneCoroutine{Active}@4368e748, state: SUSPENDED

Coroutine "selector#79":StandaloneCoroutine{Cancelling}@367b4e05, state: SUSPENDED
  at io.ktor.network.selector.ActorSelectorManager.receiveOrNullSuspend(ActorSelectorManager.kt:168)
	at io.ktor.network.selector.ActorSelectorManager.process(ActorSelectorManager.kt:90)
	at io.ktor.network.selector.ActorSelectorManager$1.invokeSuspend(ActorSelectorManager.kt:44)
	at _COROUTINE._CREATION._(CoroutineDebugging.kt:30)
	at kotlin.coroutines.intrinsics.IntrinsicsKt__IntrinsicsJvmKt.createCoroutineUnintercepted(IntrinsicsJvm.kt:161)
	at kotlinx.coroutines.intrinsics.CancellableKt.startCoroutineCancellable(Cancellable.kt:26)
	at kotlinx.coroutines.BuildersKt__Builders_commonKt.launch$default(Builders.common.kt:44)
	at kotlinx.coroutines.BuildersKt.launch$default(Unknown Source)
	at io.ktor.network.selector.ActorSelectorManager.<init>(ActorSelectorManager.kt:39)
	at io.ktor.network.selector.SelectorManagerKt.SelectorManager(SelectorManager.kt:13)
	at …the line in the example with 'SelectorManager(currentCoroutineContext())'

The lifecycle of the SelectorManager should be controllable through structured concurrency garantees.

Server

CIO: request-handler coroutine leak on half-closed idle connection after ≥1MB response

https://youtrack.jetbrains.com/issue/KTOR-9741

To reproduce, execute the following test:

import io.ktor.client.*
import io.ktor.client.engine.okhttp.*
import io.ktor.client.request.*
import io.ktor.client.statement.*
import io.ktor.server.application.*
import io.ktor.server.cio.*
import io.ktor.server.engine.*
import io.ktor.server.metrics.micrometer.*
import io.ktor.server.response.*
import io.ktor.server.routing.*
import io.ktor.util.*
import io.micrometer.prometheusmetrics.PrometheusConfig
import io.micrometer.prometheusmetrics.PrometheusMeterRegistry
import kotlinx.coroutines.CoroutineName
import kotlin.test.Test
import kotlin.time.Duration
import kotlin.time.Duration.Companion.minutes
import kotlin.time.Duration.Companion.seconds
import kotlin.time.TimeSource
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.Job
import kotlinx.coroutines.delay
import kotlinx.coroutines.isActive
import kotlinx.coroutines.launch
import kotlinx.coroutines.test.runTest
import kotlinx.coroutines.withContext

class ServerTest {

    @Test
    fun `real server leaks coroutines`() = runTest(timeout = 10.minutes) {
        val metrics = PrometheusMeterRegistry(PrometheusConfig.DEFAULT)
        val job = Job()
        val server =
            embeddedServer(
                CIO,
                rootConfig = serverConfig {
                    parentCoroutineContext = job + CoroutineName("server-parent")
                    module {
                        install(MicrometerMetrics) { registry = metrics }
                        routing { get("/") { call.respondText("A".repeat(1024 * 1024)) } } // 1,048,467
                    }
                },
            ) {
                connectionIdleTimeoutSeconds = 2
                connector {
                    host = "localhost"
                    port = 14800
                }
            }

        try {
            server.start(wait = false)
            val root = server.engine.resolvedConnectors().first().let { "http://${it.host}:${it.port}" }

            val timeMark = TimeSource.Monotonic.markNow()
            fun log(msg: String) = println("[${timeMark.elapsedNow()}] $msg")
            suspend fun realDelay(duration: Duration) = withContext(Dispatchers.Default) { delay(duration) }

            log("server running on $root")
            val monitor = backgroundScope.launch {
                while (isActive) {
                    metrics.scrape().lineSequence().filter { it.startsWith("ktor_http_server_requests_active") }
                        .forEach(::log)
                    job.printDebugTree()
                    realDelay(1.seconds)
                }
            }

            HttpClient(OkHttp) { expectSuccess = true }
                .use { httpClient ->
                    repeat(4) {
                        log("---- requesting...")
                        httpClient.get(root).bodyAsText().also { log("received: ${it.length}") }
                        realDelay(4.seconds)
                    }
                    log("closing client...")
                }
            realDelay(4.seconds)
            monitor.cancel()
        } finally {
            server.stop(0, 0)
            job.printDebugTree()
            job.complete()
        }
    }
}

As a result, the CIO server leaks request-handler couroutines:

[5.137217667s] ktor_http_server_requests_active 1.0
JobImpl{Active}@6e4c0d8c
  SupervisorJobImpl{Active}@5c5d6175
  "server-parent#3":LazyStandaloneCoroutine{Active}@7544ac86
    "server-root-HttpServerSettings(host=localhost, port=14800, connectionIdleTimeoutSeconds=2, reuseAddress=false)#7":StandaloneCoroutine{Active}@3b27b497
      SupervisorJobImpl{Active}@b1534d3
        "http-pipeline#15":StandaloneCoroutine{Completing}@4e49ce2b
          "request-handler#20":StandaloneCoroutine{Active}@435cc7f9
            "request-handler#20":DispatchedCoroutine{Active}@4364712f
              "request-handler#20":ScopeCoroutine{Active}@1b7a52dd
                "request-handler#20":DispatchedCoroutine{Active}@7f93dd4e
        "http-pipeline#23":StandaloneCoroutine{Active}@5ad5be4a
          "http-pipeline-writer#24":StandaloneCoroutine{Active}@3ad85136
            "http-pipeline-writer#24":TimeoutCoroutine(timeMillis=2000){Active}@737d100a
      "accept-HttpServerSettings(host=localhost, port=14800, connectionIdleTimeoutSeconds=2, reuseAddress=false)#9":StandaloneCoroutine{Active}@3c74aa0d
    "selector#8":StandaloneCoroutine{Active}@6c841199

The problem is reproducible only when the server responds with 1Mb of data or more and when the requests are sent with the OkHttp engine.

Maven + YAML config file does not work

OpenAPI: JsonSchema title is truncated when it contains a dot

HoconConfigLoader is not loaded when ktor-server-config-yaml on the classpath

OpenAPI: schema for kotlinx.serialization sealed types omits discriminator property in variant schemas

Netty: Close channel connection on errors properly

Netty HTTP/2: a single client-canceled stream (RST_STREAM) breaks response flushing for the whole connection

https://youtrack.jetbrains.com/issue/KTOR-9711

Affected versions

Reproduced against Ktor 3.5.1 (latest release at the time of writing) with the attached
self-contained reproducer (plaintext h2c, no TLS needed; also reproduces over TLS/ALPN).
The responsible code is unchanged on main (3.6.0-SNAPSHOT, commit
fc6595632e7412abb98b941f926d0ea13c7647d1), so the analysis below links to main.

Symptom

On any HTTP/2 connection served by the Netty engine: if the client cancels one in-flight
request with RST_STREAM before the application commits its response (browsers do this
constantly — hard refresh, navigation away, AbortController, image lazy-load cancels),
then every subsequent response multiplexed on that connection is corrupted:

responses with unknown length (chunked / respondTextWriter / SSE-like): the client
receives all body bytes but the final empty DATA(endStream=true) frame is never
flushed — the request never completes and the browser spins forever;
responses with a known body ≤ 64 KiB (the common case for HTML/JSON): nothing is
flushed at all, not even headers;
the connection never recovers until it is closed.

In Chrome this looks like: after refresh-spamming a page, some requests show the complete
payload in DevTools but stay "pending" forever.

Root cause

NettyHttp2Handler is @ChannelHandler.Sharable and is installed once per connection via
Http2MultiplexCodecBuilder.forServer(handler)
(NettyChannelInitializer.kt:193),
so one handler instance is shared by all Http2StreamChannels of the connection, and with it:

state: NettyHttpHandlerState — activeRequests / streamingResponses /
isCurrentRequestFullyRead / isChannelReadCompleted are connection-global
(NettyHttp2Handler.kt:49);
responseWriter: NettyHttpResponsePipeline (lateinit var) is overwritten on every
stream's channelActive
(NettyHttp2Handler.kt:84-89),
so channelReadComplete only ever calls flushIfNeeded() on the newest stream's pipeline
instance, while isDataNotFlushed of older streams' pipelines is tracked on instances that
are no longer consulted.

The final frame of every HTTP/2 response — the empty DefaultHttp2DataFrame(endStream=true) —
is written with context.write(...) (not writeAndFlush) in handleLastResponseMessage
(NettyHttpResponsePipeline.kt:145-151)
and relies on scheduleFlush() → flushIfNeeded(), which is gated by:

isDataNotFlushed.value &&
    httpHandlerState.isChannelReadCompleted.value &&
    httpHandlerState.activeRequests.value == httpHandlerState.streamingResponses.value

(NettyHttpResponsePipeline.kt:56-65)

The leak: activeRequests is incremented for every Http2HeadersFrame
(NettyHttp2Handler.kt:56)
but decremented only in handleLastResponseMessage. The failure path
respondWithFailure
(NettyHttpResponsePipeline.kt:107-122)
decrements neither activeRequests nor streamingResponses.

Sequence for a cancelled stream (default server, no plugins involved):

client sends HEADERS → activeRequests++;
client sends RST_STREAM(CANCEL) → Http2MultiplexCodec closes the stream's child
channel; the ktor handler only closes the request contentActor
(NettyHttp2Handler.kt:73-78);
the application handler later completes normally and commits a response →
respondFromBytes / sendResponse sees canRespond == false (channel inactive) →
cancelIfChannelNotActive() → cancel() → responseReady.tryFailure(...)
(NettyApplicationResponse.kt:155-167
— this is the fail-fast path introduced/hardened by KTOR-9524 / KTOR-9536; the engine's
AFTER_CALL call.finish() guarantees this promise always resolves);
the responseReady listener routes the failed promise into respondWithFailure
(NettyHttpResponsePipeline.kt:91-105)
→ activeRequests is never decremented;
from now on activeRequests == streamingResponses + 1 forever on this connection →
flushIfNeeded() is permanently false → every later response's trailing
DATA(endStream=true) (and, for small responses, headers + body too, since
isHeaderFlushNeeded() also requires activeRequests == 1) sits in the outbound buffer
indefinitely. The only bytes that still reach the client are the incidental
writeAndFlush calls inside respondWithBigBody (64 KiB threshold / drained channel)
— which is exactly why the body arrives completely while the stream never completes.

A second, milder variant: when a streaming response fails mid-write (e.g. the write into
a reset stream throws), respondWithFailure leaks activeRequests and streamingResponses
together, which keeps the flush gate balanced but permanently breaks the
isHeaderFlushNeeded() heuristic (activeRequests == 1L).

The counters were designed for HTTP/1 (one connection = one request at a time, connection
close cleans up); HTTP/2 shares them across concurrent streams whose lifetimes are
independent, and RST_STREAM makes premature stream death a routine event rather than a
connection-fatal one. Related earlier fix in the same area: KTOR-9421 ("active SSE connection
blocks HTTP/2 response flushing for other requests") addressed the case where a live
streaming response holds activeRequests above zero by introducing the streamingResponses
counter — but the failure/cancellation path was left out of the bookkeeping.

Reproducer (attached, self-contained)

gradle run starts a ktor 3.5.1 Netty server with enableH2c = true on 127.0.0.1:18080 and
drives it with a raw Netty h2c prior-knowledge client on the same connection:

phase 1: GET /slow (handler delays 400 ms), client sends RST_STREAM(CANCEL) after 100 ms;
phase 2: GET /data (~8 KiB via respondTextWriter);
phase 3: GET /slow again.

Observed output against 3.5.1:

== phase 1: GET /slow, cancel it with RST_STREAM after 100ms (simulates browser refresh) ==
== phase 2: GET /data (chunked ~8KB) on the same connection ==
[phase 2] GET /data -> headers=true bodyBytes=8200 endStream=false *** HUNG (timeout 5s) ***
== phase 3: GET /slow again on the same connection ==
[phase 3] GET /slow -> headers=false bodyBytes=0 endStream=false *** HUNG (timeout 3s) ***

RESULT: BUG REPRODUCED - connection is permanently poisoned after one cancelled stream:
  - phase 2 received the body but never END_STREAM (browser would spin forever)
  - phase 3 got no response at all (headers never flushed)

Control run (gradle run --args=control, identical except no RST_STREAM):

[phase 1] GET /slow -> headers=true bodyBytes=18 endStream=true COMPLETED
[phase 2] GET /data -> headers=true bodyBytes=8200 endStream=true COMPLETED
[phase 3] GET /slow -> headers=true bodyBytes=18 endStream=true COMPLETED

RESULT: all requests completed - no bug observed

Suggested fix directions

Minimal: perform the same state bookkeeping in respondWithFailure as in
handleLastResponseMessage (decrement activeRequests via onLastResponseMessage, and
streamingResponses when call.isStreamingResponse), so a failed/cancelled call cannot
desynchronize the connection-global gate.
Structural: give each HTTP/2 stream its own NettyHttpHandlerState + response pipeline
(each Http2StreamChannel is already a separate Netty channel; the cross-request ordering
and flush-coalescing heuristics inherited from the HTTP/1 pipelining design don't apply to
multiplexed streams). This would also fix responseWriter being reassigned per stream on
the shared @Sharable handler, which currently leaves isDataNotFlushed tracked on
pipeline instances that channelReadComplete no longer consults, and it makes the
streamingResponses workaround from KTOR-9421 unnecessary (with at most one request per
state, the counters cannot be held hostage by an unrelated stream).

For what it's worth, we have been running exactly this shape in production since March 2026
as a vendored copy of ktor-server-netty: NettyHttp2Handler loses @Sharable and is
instantiated per stream by a ChannelInitializer<Http2StreamChannel> handed to
Http2MultiplexHandler, each instance owning its own NettyHttpHandlerState and
NettyHttpResponsePipeline; combined with an explicit context.flush() on
HEADERS(endStream) / DATA(endStream) / RST_STREAM it eliminated the hang completely under
heavy browser refresh-spam.

RateLimit: No access to principal when wrapped with authentication since 3.5.1

`ApplicationCall.isStaticContent` returns false when called from plugin interceptors

RateLimit: Allow limit requests based on authentication result

https://youtrack.jetbrains.com/issue/KTOR-8032

Currently, it is not possible to filter rate-limits by the authentication status of a request.
Such a feature would be useful when you want to allow for routes to be still publicly accessible, however you wish to use more aggressive rate limits for unauthenticated users.

Here is some example code showcasing the issue:

private val logger by getLogger()

sealed interface SyrupPrincipal {
    val authenticated: Boolean
    val name: String
}

data class AuthenticatedSyrupUser(
    override val name: String,
) : SyrupPrincipal {
    override val authenticated = true
}

data object UnauthenticatedSyrupUser : SyrupPrincipal {
    override val authenticated = false
    override val name = "Anonymous User"
}

install(Authentication) {
    bearer {
        authHeader { call ->
            logger.info { "Parsing authentication header" }
            call.request.parseAuthorizationHeader() ?: HttpAuthHeader.Single(AuthScheme.Bearer, "Unauthenticated")
        }

        authenticate { bearer ->
            logger.info { "bearer: $bearer" }
            when (bearer.token) {
                "Unauthenticated" -> UnauthenticatedSyrupUser
                else -> AuthenticatedSyrupUser(bearer.token) // TODO: 2025-01-07 Actual authentication
            }
        }
    }
}

install(RateLimit) {
    global {
        requestKey { call ->
            val principal = call.principal<SyrupPrincipal>()
            logger.info { "key request called with $principal" }
            if (principal?.authenticated == true) principal.name else call.request.origin.remoteAddress
        }

        rateLimiter { call, key ->
            val principal = call.principal<SyrupPrincipal>()
            val limit = if (principal?.authenticated == true) 256 else 64
            logger.info { "rate limiter called with $principal" }
            // the redis rate limiter is just a simple rate limiter that checks redis for the remaining requests
            redisRateLimiter(key.toString(), limit, 5.seconds, Syrup.redisPool)
        }
    }
}

If you perform a request using (assuming ktor is launched on the default port)

curl localhost:8080/test -v -H 'Authorization: Bearer 123'

then, this will always result in the following logs:

2025-01-09 00:53:05.434 [eventLoopGroupProxy-6-1 @call-handler#107]  TRACE i.k.s.plugins.ratelimit.RateLimit - Using rate limit RateLimitName(name=KTOR_GLOBAL_RATE_LIMITER) for /test
2025-01-09 00:53:05.436 [eventLoopGroupProxy-6-1 @call-handler#107]  INFO  g.solonovamax.syrup.ktor.Responses - key request called with null
2025-01-09 00:53:05.436 [eventLoopGroupProxy-6-1 @call-handler#107]  TRACE i.k.s.plugins.ratelimit.RateLimit - Using key=0:0:0:0:0:0:0:1 and weight=1 for /test
2025-01-09 00:53:05.436 [eventLoopGroupProxy-6-1 @call-handler#107]  INFO  g.solonovamax.syrup.ktor.Responses - rate limiter called with null
2025-01-09 00:53:05.449 [eventLoopGroupProxy-6-1 @call-handler#107]  TRACE i.k.s.plugins.ratelimit.RateLimit - Allowing /test
2025-01-09 00:53:05.450 [eventLoopGroupProxy-6-1 @call-handler#107]  TRACE io.ktor.server.routing.Routing - Trace for [test]
/, segment:0 -> SUCCESS @ /
  /(authenticate "default"), segment:0 -> SUCCESS @ /(authenticate "default")
    /(authenticate "default")/test, segment:1 -> SUCCESS @ /(authenticate "default")/test
      /(authenticate "default")/test/(method:GET), segment:1 -> SUCCESS @ /(authenticate "default")/test/(method:GET)
Matched routes:
  "" -> "(authenticate "default")" -> "test" -> "(method:GET)"
Routing resolve result:
  SUCCESS @ /(authenticate "default")/test/(method:GET)
2025-01-09 00:53:05.450 [eventLoopGroupProxy-6-1 @call-handler#107]  TRACE io.ktor.server.auth.Authentication - Trying to authenticate /test with null
2025-01-09 00:53:05.450 [eventLoopGroupProxy-6-1 @call-handler#107]  INFO  gay.solonovamax.syrup.ktor.Security - Here is auth header: Bearer 123
2025-01-09 00:53:05.451 [eventLoopGroupProxy-6-1 @call-handler#107]  INFO  gay.solonovamax.syrup.ktor.Security - bearer: BearerTokenCredential(token=123)
2025-01-09 00:53:05.451 [eventLoopGroupProxy-6-1 @call-handler#107]  TRACE io.ktor.server.auth.Authentication - Authentication succeeded for /test with provider io.ktor.server.auth.BearerAuthenticationProvider@60a18ffc

The most important log messages to note are:

2025-01-09 00:53:05.434 [eventLoopGroupProxy-6-1 @call-handler#107]  TRACE i.k.s.plugins.ratelimit.RateLimit - Using rate limit RateLimitName(name=KTOR_GLOBAL_RATE_LIMITER) for /test
2025-01-09 00:53:05.436 [eventLoopGroupProxy-6-1 @call-handler#107]  INFO  g.solonovamax.syrup.ktor.Responses - key request called with null
2025-01-09 00:53:05.436 [eventLoopGroupProxy-6-1 @call-handler#107]  TRACE i.k.s.plugins.ratelimit.RateLimit - Using key=0:0:0:0:0:0:0:1 and weight=1 for /test
2025-01-09 00:53:05.436 [eventLoopGroupProxy-6-1 @call-handler#107]  INFO  g.solonovamax.syrup.ktor.Responses - rate limiter called with null
2025-01-09 00:53:05.449 [eventLoopGroupProxy-6-1 @call-handler#107]  TRACE i.k.s.plugins.ratelimit.RateLimit - Allowing /test
2025-01-09 00:53:05.450 [eventLoopGroupProxy-6-1 @call-handler#107]  TRACE io.ktor.server.auth.Authentication - Trying to authenticate /test with null
2025-01-09 00:53:05.450 [eventLoopGroupProxy-6-1 @call-handler#107]  INFO  gay.solonovamax.syrup.ktor.Security - Here is auth header: Bearer 123
2025-01-09 00:53:05.451 [eventLoopGroupProxy-6-1 @call-handler#107]  INFO  gay.solonovamax.syrup.ktor.Security - bearer: BearerTokenCredential(token=123)
2025-01-09 00:53:05.451 [eventLoopGroupProxy-6-1 @call-handler#107]  TRACE io.ktor.server.auth.Authentication - Authentication succeeded for /test with provider io.ktor.server.auth.BearerAuthenticationProvider@60a18ffc

As you can see, it is attempting to resolve the rate limit before the authentication has been processed.

Auto-reloading: server is reloaded only once since 3.5.0

SwaggerUI: Missing oauth2-redirect.html support in the plugin

Improve KDoc for EmbeddedServer.addShutdownHook

Shared

ContentNegotiation: it doesn't handle content type suffixes

Other

Reject whitespace in URL hosts during parsing

3.5.1

released 29th June 2026

Client

HttpTimeout: HttpRequestTimeoutException on any request with runTest and request timeout defined since 3.5.0

https://youtrack.jetbrains.com/issue/KTOR-9596

After update from 3.4.3 to 3.5.0, some tests that use MockEngine started throwing HttpRequestTimeoutException. Also, tests that assert whether exception was thrown became flaky (sometimes HttpRequestTimeoutException is thrown instead of the expected one).

Commit with failing tests
Affected tests are in BackendApiClientTest and QuizApiClientTest classes.

Example output:

Request timeout has expired [url=https://abcde:12345/answers, request_timeout=10000 ms]
io.ktor.client.plugins.HttpRequestTimeoutException: Request timeout has expired [url=https://abcde:12345/answers, request_timeout=10000 ms]
	at app//io.ktor.client.plugins.HttpTimeoutKt$applyRequestTimeout$killer$1.invokeSuspend(HttpTimeout.kt:186)
	at app//kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:34)
	at app//kotlinx.coroutines.DispatchedTaskKt.resume(DispatchedTask.kt:233)
	at app//kotlinx.coroutines.DispatchedTaskKt.dispatch(DispatchedTask.kt:152)
	at app//kotlinx.coroutines.CancellableContinuationImpl.dispatchResume(CancellableContinuationImpl.kt:470)
	at app//kotlinx.coroutines.CancellableContinuationImpl.resumeImpl$kotlinx_coroutines_core(CancellableContinuationImpl.kt:504)
	at app//kotlinx.coroutines.CancellableContinuationImpl.resumeImpl$kotlinx_coroutines_core$default(CancellableContinuationImpl.kt:493)
	at app//kotlinx.coroutines.CancellableContinuationImpl.resumeUndispatched(CancellableContinuationImpl.kt:596)
	at app//kotlinx.coroutines.test.CancellableContinuationRunnable.run(TestDispatcher.kt:58)
	at app//kotlinx.coroutines.test.TestDispatcher.processEvent$kotlinx_coroutines_test(TestDispatcher.kt:24)
	at app//kotlinx.coroutines.test.TestCoroutineScheduler.tryRunNextTaskUnless$kotlinx_coroutines_test(TestCoroutineScheduler.kt:98)
	at app//kotlinx.coroutines.test.TestBuildersKt__TestBuildersKt$runTest$2$1$workRunner$1.invokeSuspend(TestBuilders.kt:326)
	at app//kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:34)
	at app//kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:100)
	at app//kotlinx.coroutines.EventLoopImplBase.processNextEvent(EventLoop.common.kt:256)
	at app//kotlinx.coroutines.BlockingCoroutine.joinBlocking(Builders.kt:54)
	at app//kotlinx.coroutines.BuildersKt__BuildersKt.runBlockingImpl(Builders.kt:30)
	at app//kotlinx.coroutines.BuildersKt.runBlockingImpl(Unknown Source)
	at app//kotlinx.coroutines.BuildersKt__Builders_concurrentKt.runBlockingK(Builders.concurrent.kt:172)
	at app//kotlinx.coroutines.BuildersKt.runBlockingK(Unknown Source)
	at app//kotlinx.coroutines.BuildersKt__Builders_concurrentKt.runBlockingK$default(Builders.concurrent.kt:157)
	at app//kotlinx.coroutines.BuildersKt.runBlockingK$default(Unknown Source)
	at app//kotlinx.coroutines.test.TestBuildersJvmKt.createTestResult(TestBuildersJvm.kt:10)
	at app//kotlinx.coroutines.test.TestBuildersKt__TestBuildersKt.runTest-8Mi8wO0(TestBuilders.kt:309)
	at app//kotlinx.coroutines.test.TestBuildersKt.runTest-8Mi8wO0(TestBuilders.kt:1)
	at app//kotlinx.coroutines.test.TestBuildersKt__TestBuildersKt.runTest-8Mi8wO0(TestBuilders.kt:167)
	at app//kotlinx.coroutines.test.TestBuildersKt.runTest-8Mi8wO0(TestBuilders.kt:1)
	at app//kotlinx.coroutines.test.TestBuildersKt__TestBuildersKt.runTest-8Mi8wO0$default(TestBuilders.kt:159)
	at app//kotlinx.coroutines.test.TestBuildersKt.runTest-8Mi8wO0$default(TestBuilders.kt:1)
	at app//com.example.techquiz.data.remote.client.BackendApiClientTest.GIVEN user UUID and data WHEN save answers THEN return(BackendApiClientTest.kt:47)
	at java.base@21.0.10/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown Source)
	at java.base@21.0.10/java.lang.reflect.Method.invoke(Unknown Source)
	at app//org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at app//org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at app//org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at app//org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at app//org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at app//org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at app//org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
	at app//org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
	at app//org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
	at app//org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
	at app//org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
	at app//org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
	at app//org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
	at app//org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
	at app//org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
	at app//org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at app//org.junit.runners.ParentRunner.run(ParentRunner.java:413)
	at app//org.junit.runner.JUnitCore.run(JUnitCore.java:137)
	at app//org.junit.runner.JUnitCore.run(JUnitCore.java:115)
	at org.gradle.api.internal.tasks.testing.junit.JUnitTestExecutor.runRequest(JUnitTestExecutor.java:175)
	at org.gradle.api.internal.tasks.testing.junit.JUnitTestExecutor.accept(JUnitTestExecutor.java:84)
	at org.gradle.api.internal.tasks.testing.junit.JUnitTestExecutor.accept(JUnitTestExecutor.java:47)
	at org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestDefinitionProcessor.processTestDefinition(AbstractJUnitTestDefinitionProcessor.java:65)
	at org.gradle.api.internal.tasks.testing.SuiteTestDefinitionProcessor.processTestDefinition(SuiteTestDefinitionProcessor.java:53)
	at java.base@21.0.10/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown Source)
	at java.base@21.0.10/java.lang.reflect.Method.invoke(Unknown Source)
	at org.gradle.internal.dispatch.MethodInvocation.invokeOn(MethodInvocation.java:77)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:28)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:19)
	at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33)
	at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:88)
	at jdk.proxy1/jdk.proxy1.$Proxy4.processTestDefinition(Unknown Source)
	at org.gradle.api.internal.tasks.testing.worker.TestWorker$2.run(TestWorker.java:178)
	at org.gradle.api.internal.tasks.testing.worker.TestWorker.executeAndMaintainThreadName(TestWorker.java:126)
	at org.gradle.api.internal.tasks.testing.worker.TestWorker.execute(TestWorker.java:103)
	at org.gradle.api.internal.tasks.testing.worker.TestWorker.execute(TestWorker.java:63)
	at org.gradle.process.internal.worker.child.ActionExecutionWorker.execute(ActionExecutionWorker.java:56)
	at org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:122)
	at org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:72)
	at app//worker.org.gradle.process.internal.worker.GradleWorkerMain.run(GradleWorkerMain.java:69)
	at app//worker.org.gradle.process.internal.worker.GradleWorkerMain.main(GradleWorkerMain.java:74)

Output from one of the flaky tests:

org.opentest4j.AssertionFailedError: Expected exception io.ktor.client.plugins.ClientRequestException but a HttpRequestTimeoutException was thrown instead.
	at io.kotest.assertions.AssertionErrorBuilder_jvmKt.createAssertionError(AssertionErrorBuilder.jvm.kt:58)
	at io.kotest.assertions.AssertionErrorBuilder.build(AssertionErrorBuilder.kt:74)
	at com.example.techquiz.data.remote.client.BackendApiClientTest$GIVEN user UUID and error WHEN get most answered categories THEN throw$1.invokeSuspend(BackendApiClientTest.kt:273)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:34)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:98)
	at kotlinx.coroutines.test.TestDispatcher.processEvent$kotlinx_coroutines_test(TestDispatcher.kt:24)
	at kotlinx.coroutines.test.TestCoroutineScheduler.tryRunNextTaskUnless$kotlinx_coroutines_test(TestCoroutineScheduler.kt:98)
	at kotlinx.coroutines.test.TestBuildersKt__TestBuildersKt$runTest$2$1$workRunner$1.invokeSuspend(TestBuilders.kt:326)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:34)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:100)
	at kotlinx.coroutines.EventLoopImplBase.processNextEvent(EventLoop.common.kt:256)
	at kotlinx.coroutines.BlockingCoroutine.joinBlocking(Builders.kt:54)
	at kotlinx.coroutines.BuildersKt__BuildersKt.runBlockingImpl(Builders.kt:30)
	at kotlinx.coroutines.BuildersKt.runBlockingImpl(Unknown Source)
	at kotlinx.coroutines.BuildersKt__Builders_concurrentKt.runBlockingK(Builders.concurrent.kt:172)
	at kotlinx.coroutines.BuildersKt.runBlockingK(Unknown Source)
	at kotlinx.coroutines.BuildersKt__Builders_concurrentKt.runBlockingK$default(Builders.concurrent.kt:157)
	at kotlinx.coroutines.BuildersKt.runBlockingK$default(Unknown Source)
	at kotlinx.coroutines.test.TestBuildersJvmKt.createTestResult(TestBuildersJvm.kt:10)
	at kotlinx.coroutines.test.TestBuildersKt__TestBuildersKt.runTest-8Mi8wO0(TestBuilders.kt:309)
	at kotlinx.coroutines.test.TestBuildersKt.runTest-8Mi8wO0(TestBuilders.kt:1)
	at kotlinx.coroutines.test.TestBuildersKt__TestBuildersKt.runTest-8Mi8wO0(TestBuilders.kt:167)
	at kotlinx.coroutines.test.TestBuildersKt.runTest-8Mi8wO0(TestBuilders.kt:1)
	at kotlinx.coroutines.test.TestBuildersKt__TestBuildersKt.runTest-8Mi8wO0$default(TestBuilders.kt:159)
	at kotlinx.coroutines.test.TestBuildersKt.runTest-8Mi8wO0$default(TestBuilders.kt:1)
	at com.example.techquiz.data.remote.client.BackendApiClientTest.GIVEN user UUID and error WHEN get most answered categories THEN throw(BackendApiClientTest.kt:138)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown Source)
	at java.base/java.lang.reflect.Method.invoke(Unknown Source)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
	at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
	at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
	at org.gradle.api.internal.tasks.testing.junit.JUnitTestExecutor.runRequest(JUnitTestExecutor.java:175)
	at org.gradle.api.internal.tasks.testing.junit.JUnitTestExecutor.accept(JUnitTestExecutor.java:84)
	at org.gradle.api.internal.tasks.testing.junit.JUnitTestExecutor.accept(JUnitTestExecutor.java:47)
	at org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestDefinitionProcessor.processTestDefinition(AbstractJUnitTestDefinitionProcessor.java:65)
	at org.gradle.api.internal.tasks.testing.SuiteTestDefinitionProcessor.processTestDefinition(SuiteTestDefinitionProcessor.java:53)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown Source)
	at java.base/java.lang.reflect.Method.invoke(Unknown Source)
	at org.gradle.internal.dispatch.MethodInvocation.invokeOn(MethodInvocation.java:77)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:28)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:19)
	at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33)
	at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:88)
	at jdk.proxy1/jdk.proxy1.$Proxy4.processTestDefinition(Unknown Source)
	at org.gradle.api.internal.tasks.testing.worker.TestWorker$2.run(TestWorker.java:178)
	at org.gradle.api.internal.tasks.testing.worker.TestWorker.executeAndMaintainThreadName(TestWorker.java:126)
	at org.gradle.api.internal.tasks.testing.worker.TestWorker.execute(TestWorker.java:103)
	at org.gradle.api.internal.tasks.testing.worker.TestWorker.execute(TestWorker.java:63)
	at org.gradle.process.internal.worker.child.ActionExecutionWorker.execute(ActionExecutionWorker.java:56)
	at org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:122)
	at org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:72)
	at worker.org.gradle.process.internal.worker.GradleWorkerMain.run(GradleWorkerMain.java:69)
	at worker.org.gradle.process.internal.worker.GradleWorkerMain.main(GradleWorkerMain.java:74)
Caused by: io.ktor.client.plugins.HttpRequestTimeoutException: Request timeout has expired [url=https://abcde:12345/stats/most_answered_categories?userUuid=b0dc1232-72ca-40c1-9dca-9a886ef3c99b&count=3, request_timeout=10000 ms]
	at app//io.ktor.client.plugins.HttpTimeoutKt$applyRequestTimeout$killer$1.invokeSuspend(HttpTimeout.kt:186)
	at app//kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:34)
	at app//kotlinx.coroutines.DispatchedTaskKt.resume(DispatchedTask.kt:233)
	at app//kotlinx.coroutines.DispatchedTaskKt.dispatch(DispatchedTask.kt:152)
	at app//kotlinx.coroutines.CancellableContinuationImpl.dispatchResume(CancellableContinuationImpl.kt:470)
	at app//kotlinx.coroutines.CancellableContinuationImpl.resumeImpl$kotlinx_coroutines_core(CancellableContinuationImpl.kt:504)
	at app//kotlinx.coroutines.CancellableContinuationImpl.resumeImpl$kotlinx_coroutines_core$default(CancellableContinuationImpl.kt:493)
	at app//kotlinx.coroutines.CancellableContinuationImpl.resumeUndispatched(CancellableContinuationImpl.kt:596)
	at app//kotlinx.coroutines.test.CancellableContinuationRunnable.run(TestDispatcher.kt:58)
	... 64 more

Caching always missing with Content Negotiation

	Value
Stored (`joinToString(",")`)	`"application/vnd.github+json,application/json"`
Lookup (`joinToString(";")`)	`"application/vnd.github+json;application/json"`

WebRtcPeerConnection::close causes ClosedReceiveChannelException for other peer

https://youtrack.jetbrains.com/issue/KTOR-9610

If a WebRtcPeerConnection, with an active data channel, is closed, the other peer crashes with a ClosedReceiveChannelException :

kotlinx.coroutines.channels.ClosedReceiveChannelException: Channel was closed
                 	at kotlinx.coroutines.channels.BufferedChannel.getReceiveException(BufferedChannel.kt:1739)
                 	at kotlinx.coroutines.channels.BufferedChannel.resumeWaiterOnClosedChannel(BufferedChannel.kt:2181)
                 	at kotlinx.coroutines.channels.BufferedChannel.resumeReceiverOnClosedChannel(BufferedChannel.kt:2170)
                 	at kotlinx.coroutines.channels.BufferedChannel.cancelSuspendedReceiveRequests(BufferedChannel.kt:2163)
                 	at kotlinx.coroutines.channels.BufferedChannel.completeClose(BufferedChannel.kt:1940)
                 	at kotlinx.coroutines.channels.BufferedChannel.isClosed(BufferedChannel.kt:2219)
                 	at kotlinx.coroutines.channels.BufferedChannel.isClosedForSend0(BufferedChannel.kt:2194)
                 	at kotlinx.coroutines.channels.BufferedChannel.isClosedForSend(BufferedChannel.kt:2191)
                 	at kotlinx.coroutines.channels.BufferedChannel.completeCloseOrCancel(BufferedChannel.kt:1912)
                 	at kotlinx.coroutines.channels.BufferedChannel.closeOrCancelImpl(BufferedChannel.kt:1805)
                 	at kotlinx.coroutines.channels.BufferedChannel.close(BufferedChannel.kt:1764)
                 	at kotlinx.coroutines.channels.SendChannel.close$default(Channel.kt:263)
                 	at io.ktor.client.webrtc.WebRtcDataChannel.stopReceivingMessages(WebRtcDataChannel.kt:225)
                 	at io.ktor.client.webrtc.AndroidWebRtcDataChannel$setupEvents$1$onStateChange$$inlined$runInConnectionScope$1.invokeSuspend(DataChannel.kt:144)
                 	at io.ktor.client.webrtc.AndroidWebRtcDataChannel$setupEvents$1$onStateChange$$inlined$runInConnectionScope$1.invoke(Unknown Source:8)
                 	at io.ktor.client.webrtc.AndroidWebRtcDataChannel$setupEvents$1$onStateChange$$inlined$runInConnectionScope$1.invoke(Unknown Source:4)
                 	at kotlinx.coroutines.intrinsics.UndispatchedKt.startCoroutineUndispatched(Undispatched.kt:20)
                 	at kotlinx.coroutines.CoroutineStart.invoke(CoroutineStart.kt:360)
                 	at kotlinx.coroutines.AbstractCoroutine.start(AbstractCoroutine.kt:134)
                 	at kotlinx.coroutines.BuildersKt__Builders_commonKt.launch(Builders.common.kt:209)
                 	at kotlinx.coroutines.BuildersKt.launch(Unknown Source:1)
                 	at kotlinx.coroutines.BuildersKt__Builders_commonKt.launch$default(Builders.common.kt:200)
                 	at kotlinx.coroutines.BuildersKt.launch$default(Unknown Source:1)
                 	at io.ktor.client.webrtc.AndroidWebRtcDataChannel$setupEvents$1.onStateChange(DataChannel.kt:139)
                 	Suppressed: kotlinx.coroutines.internal.DiagnosticCoroutineContextException: [CoroutineName(Peer-A-Scope), StandaloneCoroutine{Cancelling}@8fcbbbb, Dispatchers.Default]

I attached a demo project that showcases the issue:

git clone demo.bundle
Run the app on Android (I think other platforms are also affected, but I tested on Android)
Click the button "Setup Call"
Click the button "Disconnect PeerB"
Observe how PeerA crashes with the above stacktrace

HttpCache: InvalidCacheStateException is thrown on 304 when no cached entry matches varyKeys

https://youtrack.jetbrains.com/issue/KTOR-9661

Summary:

On a 304 Not Modified, HttpCache throws InvalidCacheStateException whenever findAndRefresh returns null — i.e. when no cached entry's varyKeys match the response's varyKeys. KTOR-8345 / PR #4816 ("Make Vary Header check lenient") only softened the case where an entry is found but its Vary size differs (it now logs a warning and proceeds). It did not touch the null branch, which still throws unconditionally.

Where:

ktor-client-core → io.ktor.client.plugins.cache.HttpCache, receive interceptor:

if (response.status == HttpStatusCode.NotModified) {
    val responseFromCache =
        plugin.findAndRefresh(response.call.request, response)
            ?: throw InvalidCacheStateException(response.call.request.url)   // ← this line
    if (responseFromCache.varyKeys().size != response.varyKeys().size) {
        LOGGER.warn("... Falling back to missing cache logic ...")          // ← #4816, only reached if non-null
    }
    ...
}

How it happens in practice:

A very common trigger is a server-side CORS change that adds Vary: Origin:

A response is cached while it has no Vary header → stored with varyKeys = {}.
The backend later starts sending Vary: Origin (CORS). On revalidation the 304 carries Vary: Origin, so response.varyKeys() = {"Origin": ""} (native client sends no Origin).
storage.find(url, {"Origin": ""}) finds nothing (stored entry has {}) → findAndRefresh returns null → throws.

Critically, the throw happens before the entry can be refreshed, so the bad entry is never replaced — the client stays permanently stuck on that URL until the cache is cleared.

Minimal reproduction (MockEngine):

val etag = "\"v1\""
val engine = MockEngine { request ->
    if (request.headers.contains(HttpHeaders.IfNoneMatch)) {
        respond("", HttpStatusCode.NotModified, headersOf(
            HttpHeaders.ETag to listOf(etag),
            // vary added here
            HttpHeaders.Vary to listOf("Origin"),
        ))
    } else {
        respond("body", HttpStatusCode.OK, headersOf(
            HttpHeaders.ETag to listOf(etag),
            HttpHeaders.CacheControl to listOf("max-age=0, must-revalidate"), // force revalidation
            // note: NO Vary on the 200
        ))
    }
}
val client = HttpClient(engine) { install(HttpCache) }

client.get("https://example.com/x").bodyAsText()   // caches with varyKeys = {}

// Throws
client.get("https://example.com/x").bodyAsText()   // 304 carries Vary: Origin → InvalidCacheStateException

Suggested fix:

Apply the same leniency to the null branch: on findAndRefresh == null, fall back to a fresh network fetch (and replace the stale entry) instead of throwing. The current LOGGER.warn even references "Falling back to missing cache logic," but the code doesn't actually do so.

ContentNegotiation: The charset of `Accept-Charset` header is used for response deserialization

https://youtrack.jetbrains.com/issue/KTOR-9574

The client ContentNegotiation plugin decodes the response body using the charset derived from the outgoing request headers (Accept-Charset) instead of the charset declared in the response's Content-Type header. This causes incorrect decoding (Mojibake or parse errors) for any server that responds with a non-UTF-8 charset, such as Content-Type: application/xml; charset=utf-16.

In ContentNegotiation.kt, the transformResponseBody block reads the charset from the request headers:

transformResponseBody { response, body, info ->
    val contentType = response.contentType() ?: return@transformResponseBody null
    val charset = response.request.headers.suitableCharset()

    convertResponse(response.request.url, info, body, contentType, charset)
}

suitableCharset() is defined as:

/**
 * Detect suitable charset for an application call by `Accept` header or fallback to [defaultCharset]
 *
 * [Report a problem](https://ktor.io/feedback/?fqname=io.ktor.serialization.suitableCharset)
 */
public fun Headers.suitableCharset(defaultCharset: Charset = Charsets.UTF_8): Charset =
    suitableCharsetOrNull(defaultCharset) ?: defaultCharset

/**
 * Detect suitable charset for an application call by `Accept` header or fallback to null
 *
 * [Report a problem](https://ktor.io/feedback/?fqname=io.ktor.serialization.suitableCharsetOrNull)
 */
public fun Headers.suitableCharsetOrNull(defaultCharset: Charset = Charsets.UTF_8): Charset? {
    @Suppress("DEPRECATION")
    for ((charset, _) in parseAndSortHeader(get(HttpHeaders.AcceptCharset))) {
        when {
            charset == "*" -> return defaultCharset
            Charsets.isSupported(charset) -> return Charsets.forName(charset)
        }
    }
    return null
}

It reads Accept-Charset from the request headers, this always falls back to UTF-8, completely ignoring the charset the server declared in the response.

I wrote a temporary patch which fixes it by reading the charset from contentType:

transformResponseBody { response, body, info ->
    val contentType = response.contentType() ?: return@transformResponseBody null
    val charset = contentType.parameters.suitableCharset()

    convertResponse(response.request.url, info, body, contentType, charset)
}

private fun List<HeaderValueParam>.suitableCharset(defaultCharset: Charset = Charsets.UTF_8): Charset =
    suitableCharsetOrNull() ?: defaultCharset

private fun List<HeaderValueParam>.suitableCharsetOrNull(): Charset? =
    find { it.name == "charset" }?.let { charsetParam ->
        val charsetName = charsetParam.value
        if (Charsets.isSupported(charsetName)) {
            Charsets.forName(charsetName)
        } else {
            LOGGER.warn("Unsupported charset '$charsetName' in content type")
            null
        }
    }

Curl: Can't build shared library with Ktor 3.4.2

HttpRequestBuilder.timeout call removes capabilities set in DefaultRequest

Darwin: WebSocket client crashes the process when a PONG arrives after the session is closed

https://youtrack.jetbrains.com/issue/KTOR-9639

Summary

On the Darwin client engine, DarwinWebsocketSession.receiveFrame re-throws the channel close cause when _incoming is already closed. receiveFrame only runs inside the sendPingWithPongReceiveHandler block, which NSURLSession invokes on its delegate NSOperationQueue. A Kotlin throw there escapes into an Objective-C frame with no Kotlin handler to unwind into, so Kotlin/Native callsstd::terminate → abort() — the whole process crashes (SIGABRT).

Triggered by: WebSockets installed with a pingInterval, and the session cancelled with a cause while a ping/pong is in flight.

Affected versions

Reproduced on 3.4.3 and 3.5.0 (code is identical). Only the Darwin engine.

Crash signature

abort → std::__terminate → ThrowException
DarwinWebsocketSession.receiveFrame
DarwinWebsocketSession.sendMessages (pong handler)
__NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__

Root cause

ktor-client-darwin/.../internal/DarwinWebsocketSession.kt:

private fun receiveFrame(frame: Frame) {
    val result = _incoming.trySend(frame)
    when {
        result.isSuccess -> return
        result.isClosed -> result.exceptionOrNull()?.let { throw it }  // crashes inside the ObjC block
        else -> launch(start = CoroutineStart.UNDISPATCHED) { _incoming.send(frame) }
    }
}

When socketJob completes it closes _incoming (see init). A pong landing after that hits isClosed, and throw it runs on the Foundation callback thread.

Suggested fix

The session is already closing and the close cause is already delivered to consumers of incoming, so the late frame can simply be dropped instead of thrown:

private fun receiveFrame(frame: Frame) {
    val result = _incoming.trySend(frame)
    when {
        result.isSuccess -> return
        result.isClosed -> return   // session closing; never throw from this ObjC callback
        else -> launch(start = CoroutineStart.UNDISPATCHED) { _incoming.send(frame) }
    }
}

(The else branch is safe: its throw is captured by the coroutine, not propagated to the Objective-C caller.) Verified: compiles against 3.5.1-SNAPSHOT.

Workaround

Don't set WebSockets.pingInterval on Darwin (iOS/macOS) targets.

Darwin: findCharset("UTF-16") maps to NSUTF16LittleEndianStringEncoding causing decoding failure for UTF-16 content with BOM

https://youtrack.jetbrains.com/issue/KTOR-9575

On Darwin platforms (iOS/macOS), decoding a UTF-16 byte stream that contains a BOM produces completely garbled output. Every single character is decoded incorrectly, rather than just the BOM character itself. This is because findCharset("UTF-16") is hardcoded to return Charsets.UTF_16, which is internally constructed as CharsetDarwin(platformUtf16) = CharsetDarwin("UTF-16LE"), which maps to NSUTF16LittleEndianStringEncoding. This encoding does not process BOM and does not auto-detect byte order — it always treats the bytes as little-endian raw data.

In CharsetNative.kt , platformUtf16 is defined as:

internal val platformUtf16: String =
    if (ByteOrder.nativeOrder() == io.ktor.utils.io.core.ByteOrder.BIG_ENDIAN) "UTF-16BE" else "UTF-16LE"

And in CharsetDarwin.kt:

public actual object Charsets {
    ...
    internal val UTF_16: Charset = CharsetDarwin(platformUtf16)
}

internal actual fun findCharset(name: String): Charset {
    if (name == "UTF-8" || name == "utf-8" || name == "UTF8" || name == "utf8") return Charsets.UTF_8
    if (name == "ISO-8859-1" || name == "iso-8859-1" || name == "ISO_8859_1") return Charsets.ISO_8859_1
    if (name == "UTF-16" || name == "utf-16" || name == "UTF16" || name == "utf16") return Charsets.UTF_16

    return CharsetDarwin(name)
}

private class CharsetDarwin(name: String) : Charset(name) {
    @OptIn(UnsafeNumber::class)
    val encoding: NSStringEncoding = when (name.uppercase()) {
        "UTF-8" -> NSUTF8StringEncoding
        "ISO-8859-1" -> NSISOLatin1StringEncoding
        "UTF-16" -> NSUTF16StringEncoding
        "UTF-16BE" -> NSUTF16BigEndianStringEncoding
        "UTF-16LE" -> NSUTF16LittleEndianStringEncoding
        "UTF-32" -> NSUTF32StringEncoding
        "UTF-32BE" -> NSUTF32BigEndianStringEncoding
        "UTF-32LE" -> NSUTF32LittleEndianStringEncoding
        "ASCII" -> NSASCIIStringEncoding
        "NEXTSTEP" -> NSNEXTSTEPStringEncoding
        "JAPANESE_EUC" -> NSJapaneseEUCStringEncoding
        "LATIN1" -> NSISOLatin1StringEncoding
        else -> throw IllegalArgumentException("Charset $name is not supported by darwin.")
    }

    override fun newEncoder(): CharsetEncoder = object : CharsetEncoder(this) {}

    override fun newDecoder(): CharsetDecoder = object : CharsetDecoder(this) {}
}

The interception in findCharset causes "UTF-16" to be resolved as CharsetDarwin("UTF-16LE"), whose name field is "UTF-16LE". This means the when block in CharsetDarwin selects NSUTF16LittleEndianStringEncoding instead of the BOM-aware NSUTF16StringEncoding.

And Charsets.isSupported is inconsistent with CharsetDarwin's actual support

Charsets.isSupported() on posix/Darwin (defined in CharsetNative.kt) only recognizes a small hardcoded set of names:

public fun isSupported(charset: String): Boolean = when (charset) {
    "UTF-8", "utf-8", "UTF8", "utf8" -> true
    "ISO-8859-1", "iso-8859-1" -> true
    "UTF-16", "utf-16", "UTF16", "utf16" -> true
    else -> false
}

However, CharsetDarwin (the actual Darwin implementation) fully supports a much wider set of charsets:

val encoding: NSStringEncoding = when (name.uppercase()) {
    "UTF-8" -> NSUTF8StringEncoding
    "ISO-8859-1" -> NSISOLatin1StringEncoding
    "UTF-16" -> NSUTF16StringEncoding
    "UTF-16BE" -> NSUTF16BigEndianStringEncoding
    "UTF-16LE" -> NSUTF16LittleEndianStringEncoding
    "UTF-32" -> NSUTF32StringEncoding
    "UTF-32BE" -> NSUTF32BigEndianStringEncoding
    "UTF-32LE" -> NSUTF32LittleEndianStringEncoding
    "ASCII" -> NSASCIIStringEncoding
    "NEXTSTEP" -> NSNEXTSTEPStringEncoding
    "JAPANESE_EUC" -> NSJapaneseEUCStringEncoding
    "LATIN1" -> NSISOLatin1StringEncoding
    else -> throw IllegalArgumentException("Charset $name is not supported by darwin.")
}

WebRTC statistics fetching race condition

Crash on Android 7: NoSuchMethodError getInstanceStrong() since 3.5.0

Digest Auth: The plugin sends incorrect nonce when server responds with multiple WWW-Authenticate headers

CIO: The engine imports `node:net` statically and breaks wasmJsBrowser webpack build

https://youtrack.jetbrains.com/issue/KTOR-9595

Description

io.ktor:ktor-client-cio:3.5.0 breaks a Kotlin/Wasm browser build when bundled with Webpack.

The same project works with io.ktor:ktor-client-cio:3.4.1.

The failure seems related to the change introduced by KTOR-7659, where the Node.js network module is now imported as a static ESM import:

import * as bm9kZTpuZXQ from 'node:net';

In 3.4.1, the generated code used a dynamic require instead:

'io.ktor.network.sockets.nodejs.nodeNet' : () => eval('require')('node:net'),

With 3.5.0, Webpack sees the static node:net import during bundling and fails in a browser/WasmJs target.

Reproducer

Use a Kotlin Multiplatform project targeting wasmJsBrowser with ktor-client-cio.

Minimal dependency setup:

kotlin { 
  wasmJs {
        browser {}
    }
}
sourceSets {
    commonMain {
        dependencies {
            implementation("io.ktor:ktor-client-cio:3.5.0")
            implementation("io.ktor:ktor-client-content-negotiation:3.5.0")
            implementation("io.ktor:ktor-serialization-kotlinx-json:3.5.0")
        }
    }
}

Then run the browser development task, for example:

./gradlew wasmJsBrowserDevelopmentRun

Actual behavior

Webpack fails with:

Module build failed: UnhandledSchemeError: Reading from "node:net" is not handled by plugins (Unhandled scheme).

Expected behavior

ktor-client-cio is documented as available on WasmJs/browser targets, so using ktor-client-cio:3.5.0 should not introduce a static Node.js-only import that breaks Webpack browser bundling.

The browser/WasmJs bundle should either:

not include the Node.js-specific node:net import, or
keep it hidden behind a platform/runtime-specific branch that does not get resolved by browser bundlers, or
provide a browser-compatible variant that does not statically import Node.js core modules.

Regression

This appears to be a regression from 3.4.1 to 3.5.0.

Confirmed behavior:

io.ktor:ktor-client-cio:3.4.1 works.
io.ktor:ktor-client-cio:3.5.0 fails.
Forcing only ktor-client-cio back to 3.4.1 and keeping all other ktor libraries at version 3.5.0 makes the project build again.

WebRTC: Peer stops receiving messages after a while on iOS

Apache5: The underlying request is not aborted when coroutine Job is cancelled

Add more details for KDoc of BearerAuthConfig.sendWithoutRequest

Add KDoc for BearerAuthConfig.realm

Add Kdoc for BearerAuthConfig.refreshTokens

Compiler Plugin

Fix Kotlin 2.4.0 compiler plugin breaking changes

OpenAPI plugin: handle requireXxx functions in compiler plugin

Core

GMTDate() being offset by 369 years on Windows

Duplicate PROPERTY_SETTER target in @InternalAPI annotation

Docs

Update the log4j bridge version in Logging

Gradle Plugin

Gradle plugin environment variable is not included in the image

IO

OutputStreamContent and WriterContent can exhaust Dispatchers.IO

RawSourceChannel: coroutine cancellation is not propagated to the RawSource

Server

RateLimit plugin is bypassed when the nested authenticate block rejects the request

Compression: The plugin ignores Accept-Encoding q=0 and most-specific matching

DI: The close method is called twice on cleanup of AutoCloseable

CORS plugin drops OPTIONS preflight requests when allowSameOrigin is on

CORS is skipped when the Origin header contains an IPv6 address

https://youtrack.jetbrains.com/issue/KTOR-9659

Description

Ktor CORS appears to reject a browser-valid IPv6 literal origin before applying CORS host matching.

When a request contains this Origin header:

Origin: http://[::1]:22222

Ktor logs:

TRACE io.ktor.server.plugins.cors.CORS - GET /: Start handler
TRACE io.ktor.server.plugins.cors.CORS - GET /: Skip CORS handler because Origin http://[::1]:22222 is malformed

As a result, the response does not include Access-Control-Allow-Origin, even when CORS is configured with anyHost().

The same application behaves correctly when using a hostname origin:

Origin: http://localhost:22222

In that case Ktor returns:

Access-Control-Allow-Origin: *

Minimal reproducer

fun main() {
  embeddedServer(
    factory = io.ktor.server.netty.Netty,
    port = 8080,
    host = "0.0.0.0",
    module = {
      install(CORS) {
        anyHost()
      }

      routing {
        get("/") {
          call.respondText("Hello, World!")
        }
      }
    }
  ).start(wait = true)
}

Full MRE on GitHub Gist

Reproduction steps

Run the server from the MRE, then execute:

curl -i -H 'Origin: http://localhost:22222' http://localhost:8080/

Actual result:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Length: 13
Content-Type: text/plain; charset=UTF-8

Hello, World!

Then execute:

curl -i -H 'Origin: http://[::1]:22222' http://localhost:8080/

Actual result:

HTTP/1.1 200 OK
Content-Length: 13
Content-Type: text/plain; charset=UTF-8

Hello, World!

Application log:

TRACE io.ktor.server.plugins.cors.CORS - GET /: Start handler
TRACE io.ktor.server.plugins.cors.CORS - GET /: Skip CORS handler because Origin http://[::1]:22222 is malformed

Expected behavior

http://[::1]:22222 should not be treated as a malformed origin.

With anyHost() enabled, Ktor should accept this Origin and return the expected CORS response header, for example:

Access-Control-Allow-Origin: *

Why this seems valid

Browsers can serialize IPv6 literal hosts in origins using square brackets, for example:

http://[::1]:22222

Firefox sends this Origin header when a frontend is opened from:

http://[::1]:22222/

So this appears to be a valid browser-generated origin, not a malformed client request.

Possible cause

The issue seems to come from Ktor's origin validation logic in isValidOrigin:

https://github.com/ktorio/ktor/blob/main/ktor-server/ktor-server-plugins/ktor-server-cors/common/src/io/ktor/server/plugins/cors/CORSUtils.kt#L134-L164

Current logic scans the origin starting after :// and treats the first : or / as the beginning of the port/trailing part:

var portIndex = origin.length
for (index in protoDelimiter + 3 until origin.length) {
    val ch = origin[index]
    if (ch == ':' || ch == '/') {
        portIndex = index + 1
        break
    }
    if (ch == '?') return false
}

That works for origins like:

http://localhost:22222

but not for bracketed IPv6 literals like:

http://[::1]:22222

For http://[::1]:22222, the first : after :// is part of the IPv6 address, not the port separator:

http://[::1]:22222
        ^

The validator then appears to treat the rest of the IPv6 host as a port-like suffix, reaches non-digit characters, and rejects the origin as malformed.

In other words, the validation logic does not appear to account for bracketed IPv6 host syntax before applying port parsing.

Environment

From the MRE:

kotlin("jvm") version "2.4.0"
id("io.ktor.plugin") version "3.5.0"

Dependencies:

implementation("io.ktor:ktor-server-core")
implementation("io.ktor:ktor-server-cors")
implementation("io.ktor:ktor-server-netty")
implementation("ch.qos.logback:logback-classic:1.5.34")

JVM toolchain:

jvmToolchain(21)

Notes

This affects local development setups where a frontend dev server is opened via IPv6 loopback, for example:

http://[::1]:22222/

A workaround is to use localhost or 127.0.0.1 instead, but Ktor should probably accept this valid browser-generated IPv6 literal origin.

KotlinxSerializationConverter: it fails to deserialize an empty channel closed with a delay

https://youtrack.jetbrains.com/issue/KTOR-9606

Provided by me:

When route calls receiveNullable<T?>() with Content-Type: application/json and an empty body, the server sometimes returns 400 Bad Request and sometimes the 200 Success, and it depends on the network speed. You can find the reproducer in attachment. Test that is written there is failing with 400, but commenting Thread.sleep(200) part changes the service response to 200

Provided by agent:

This is a race condition introduced by how RequestBodyLimit.applyLimit wraps the incoming channel.

Root Cause

RequestBodyLimit.applyLimit always wraps the incoming ByteReadChannel via GlobalScope.writer { ... }.channel:

@OptIn(DelicateCoroutinesApi::class)

internal fun ByteReadChannel.applyLimit(limit: Long): ByteReadChannel =

    GlobalScope.writer {

        // ...

        while (!isClosedForRead) {

            val read = readAvailable(array, 0, array.size)

            // ...

        }

    }.channel

The returned channel is not immediately isClosedForRead = true — the writer coroutine must be scheduled and run first. When the body data is not yet available, the writer suspends on readAvailable. At this point, ContentNegotiation's RequestConverter checks isClosedForRead on the wrapper channel:

• If the writer has already run and closed the channel → true → body is treated as empty → receiveNullable returns null ✓

• If the writer hasn't run yet → false → KotlinxSerializationConverter calls readRemaining(), gets "", calls Json.decodeFromString("") → JsonDecodingException → 400 ✗

The race window is opened by any timing gap between the request headers arriving and the empty body terminator arriving — which is the normal case over a real network connection.

Expected Behavior

receiveNullable<T?>() should return null for an empty body regardless of whether RequestBodyLimit is installed and regardless of network timing.

Possible Fixes

In applyLimit: If the source channel is already isClosedForRead at wrap time, return an already-closed channel instead of launching a writer.
In KotlinxSerializationConverter: Treat an empty body as null for nullable reified types rather than attempting decodeFromString("").
In ContentNegotiation's RequestConverter: After readRemaining() returns an empty string, check nullability before delegating to the converter.

Option 1 is the most targeted fix and avoids the unnecessary GlobalScope.writer allocation for the common empty-body case.

OpenAPI: `@JsonClassDiscriminator` on sealed types is ignored when generating OpenAPI discriminator schema

https://youtrack.jetbrains.com/issue/KTOR-9591

Description

When a sealed interface or sealed class is annotated with @JsonClassDiscriminator("kind"), the generated OpenAPI schema always uses "type" as the discriminator.propertyName, ignoring the annotation value entirely.

This produces a mismatch between the actual JSON serialization (which correctly uses "kind" as the discriminator key) and the OpenAPI specification (which declares "type").

Steps to Reproduce

@JsonClassDiscriminator("kind")
@Serializable
sealed interface Shape {
    @Serializable
    @SerialName("circle")
    data class Circle(val radius: Double) : Shape

    @Serializable
    @SerialName("rectangle")
    data class Rectangle(val width: Double, val height: Double) : Shape
}

Expose this type as an OpenAPI response body. Inspect the generated schema.

Expected behavior

discriminator:
  propertyName: kind   # value from @JsonClassDiscriminator("kind")

Actual behavior

discriminator:
  propertyName: type     # hardcoded, annotation is not read

Root Cause

In KotlinxSerializerJsonSchemaInference.buildSchemaFromDescriptor (JsonSchemaInference.kt), the PolymorphicKind.SEALED branch reads the discriminator property name as:

val discriminatorProperty = descriptor.getElementName(0)

For a polymorphic descriptor, getElementName(0) always returns "type" regardless of any @JsonClassDiscriminator annotation on the class. Although @JsonClassDiscriminator is a @SerialInfo annotation and therefore present in descriptor.annotations, it is never consulted.

The same issue exists in ReflectionJsonSchemaInference (JsonSchemaInference.jvm.kt), where "type" is hardcoded unconditionally.

Suggested Fix

// KotlinxSerializerJsonSchemaInference
val discriminatorProperty = descriptor.annotations
    .filterIsInstance<JsonClassDiscriminator>()
    .firstOrNull()?.discriminator
    ?: descriptor.getElementName(0)

// ReflectionJsonSchemaInference
val discriminatorProperty = kClass.annotations
    .filterIsInstance<JsonClassDiscriminator>()
    .firstOrNull()?.discriminator
    ?: "type"

Affected Versions: 3.x (confirmed on 3.5.0)

SessionTransportTransformerEncrypt init block uses wrong IV size for AES-256 (regression of KTOR-661)

RoutingBuilder.contentType does not use parameters when matching

OpenAPI: nullable @JvmInline value class loses nullability in generated schema

OpenAPI: Schema name collisions because`@SerialName` of sealed subtypes is used as `components.schemas` key

https://youtrack.jetbrains.com/issue/KTOR-9597

Environment

Ktor: current main branch / latest snapshot
OpenAPI generation: ktor-server-routing-openapi
Serialization: kotlinx.serialization

Problem

When generating OpenAPI for sealed hierarchies, Ktor currently uses the sealed subtype @SerialName as the schema component name.

As a result, two different Kotlin types from different sealed hierarchies can collide in components.schemas if they reuse the same @SerialName.

This is problematic because @SerialName is part of the serialized wire format and should not also define OpenAPI component identity.

Example

@OptIn(ExperimentalSerializationApi::class)
@JsonClassDiscriminator("status")
@Serializable
sealed interface FirstResponse {
    @Serializable
    @SerialName("shared_case")
    data class SharedCase(val value: String) : FirstResponse
}

@OptIn(ExperimentalSerializationApi::class)
@JsonClassDiscriminator("status")
@Serializable
sealed interface SecondResponse {
    @Serializable
    @SerialName("shared_case")
    data class SharedCase(val count: Int) : SecondResponse
}

Actual behavior

@SerialName("shared_case") is used as the OpenAPI schema component name
distinct subtype schemas from different sealed hierarchies collide in components.schemas
avoiding the collision would require changing @SerialName, which also changes the API wire format

Expected behavior

@SerialName should continue to control the discriminator / serialized subtype identity
schema component names should remain type-based and distinct
component names should use the same approach as regular classes, ideally FQDN-based names

For the example above, expected component keys would be something like:

your.package.FirstResponse.SharedCase
your.package.SecondResponse.SharedCase

Why this matters

Schema component names and serialization wire names are separate concerns.

Using @SerialName for both causes avoidable conflicts:

discriminator values may intentionally be reused across hierarchies
OpenAPI schema names must still remain unique
changing a wire name just to fix documentation is not acceptable

Suggested behavior

Please keep:

discriminator mapping key = @SerialName

Please change:

components.schemas key and $ref target = Kotlin type-based name, consistent with normal class handling
preferably FQDN-based, to avoid collisions

For example, discriminator mapping could still be:

mapping:
  shared_case: "#/components/schemas/your.package.FirstResponse.SharedCase"

while the schema component name remains unique and stable.

Reproduction

I reproduced this locally with a regression test in ktor-server-routing-openapi using two sealed hierarchies with the same subtype @SerialName.

The test expectation is that both distinct subtype schemas should be preserved in components.schemas, but the current implementation does not keep them distinct.

File.readChannel: do not close a non-opened file and ignore closing exceptions

Zstd Compression: "Destination buffer is too small" exception for a particular sequence of bytes

Digest Auth: server must respond with one WWW-Authenticate header for each supported algorithm

Digest Auth: "Unsupported charset in digest authentication header" for a charset name in lowercase

https://youtrack.jetbrains.com/issue/KTOR-9624

To reproduce, execute the following test:

fun Application.testModule() {
    install(Authentication) {
        val userPasswords: Map<String, String> = mapOf(
            "jetbrains" to "foobar",
            "admin" to "password"
        )

        fun computeHash(userName: String, realm: String, password: String, algorithm: DigestAlgorithm): ByteArray =
            algorithm.toDigester().digest("$userName:$realm:$password".toByteArray(UTF_8))

        digest("auth-digest") {
            realm = "Ktor realm"
            algorithms = listOf(DigestAlgorithm.SHA_512_256, DigestAlgorithm.MD5)
            digestProvider { userName, realm, algorithm ->
                userPasswords[userName]?.let { password ->
                    computeHash(userName, realm, password, algorithm)
                }
            }
            validate { credentials ->
                if (credentials.userName.isNotEmpty()) {
                    credentials.userName
                } else {
                    null
                }
            }
        }
    }
    routing {
        authenticate("auth-digest") {
            get("/") {
                call.respondText("Hello, ${call.principal<String>()}!")
            }
        }
    }
}

@Test
fun `server accepts lowercase charset`() = testApplication {
    application {
        testModule()
    }

    val challengeResponse = client.get("/")
    assertEquals(HttpStatusCode.Unauthorized, challengeResponse.status)
    val wwwAuth = challengeResponse.headers[HttpHeaders.WWWAuthenticate]!!

    val nonce = Regex("""nonce="([^"]+)"""").find(wwwAuth)!!.groupValues[1]
    val realm = "Ktor realm"
    val username = "admin"
    val password = "password"

    val ha1 = md5Hex("$username:$realm:$password")
    val ha2 = md5Hex("GET:/")
    val response = md5Hex("$ha1:$nonce:$ha2")

    val authed = client.get("/") {
        header(
            HttpHeaders.Authorization,
            """Digest username="$username", realm="$realm", nonce="$nonce", uri="/", algorithm=MD5, response="$response", charset=utf-8"""
        )
    }

    assertEquals(HttpStatusCode.OK, authed.status)
}

As a result, the server responds with 500 status and throws the following exception:

java.lang.IllegalArgumentException: Unsupported charset in digest authentication header
	at io.ktor.server.auth.DigestCredentialKt.toDigestCredential(DigestCredential.kt:233)
	at io.ktor.server.auth.DigestAuthenticationProvider.onAuthenticate(DigestAuth.kt:63)
	at io.ktor.server.auth.AuthenticationInterceptorsKt$AuthenticationInterceptors$2$2.invokeSuspend(AuthenticationInterceptors.kt:136)
	at io.ktor.server.auth.AuthenticationInterceptorsKt$AuthenticationInterceptors$2$2.invoke(AuthenticationInterceptors.kt)
	at io.ktor.server.auth.AuthenticationInterceptorsKt$AuthenticationInterceptors$2$2.invoke(AuthenticationInterceptors.kt)
	at io.ktor.server.auth.AuthenticationHook$install$1.invokeSuspend(AuthenticationInterceptors.kt:29)
	at io.ktor.server.auth.AuthenticationHook$install$1.invoke(AuthenticationInterceptors.kt)
	at io.ktor.server.auth.AuthenticationHook$install$1.invoke(AuthenticationInterceptors.kt)

According to the spec, the lowercase charset names must be supported.

Shared

ContentEncoding: Incomplete gzip response causes client/server to hang indefinitely

https://youtrack.jetbrains.com/issue/KTOR-9252

It happens that a server returns malformed gzipped content; when this happens, the client hangs forever because the GZIP inflater gets stuck in an infinite loop, consuming 100% CPU.

HttpTimeout has no effect. Using withTimeout does allow the code to continue, but the thread doing the inflating will still be running burning CPU.

The loop it gets stuck in is in EnvodersJvm at

while (!inflater.needsInput() && !inflater.finished()) {
    totalSize += inflater.inflateTo(channel, writeBuffer, checksum)
    readBuffer.position(readBuffer.limit() - inflater.remaining)
}

Here is a test to reproduce the issue:


    val malformedGzip = byteArrayOf(
        0x1f, 0x8b.toByte(),    // Magic                                                                                                                                                                                                                    
        0x08,                   // Deflate method                                                                                                                                                                                                          
        0x00,                   // Flags                                                                                                                                                                                                                   
        0x00, 0x00, 0x00, 0x00, // Timestamp                                                                                                                                                                                                              
        0x00,                   // Extra flags                                                                                                                                                                                                             
        0xff.toByte(),          // OS                                                                                                                                                                                                                      
        // Incomplete deflate stream that causes Inflater to wait forever                                                                                                                                                                                 
        0x01, 0x00, 0x00
    )

    test("malformed gzip hangs forever") {
        val client = HttpClient(MockEngine) {
            engine {
                addHandler { request ->
                    respond(
                        content = malformedGzip,
                        status = HttpStatusCode.OK,
                        headers = headersOf(
                            HttpHeaders.ContentEncoding to listOf("gzip"),
                            HttpHeaders.ContentType to listOf("application/json")
                        )
                    )
                }
            }
            install(ContentEncoding) {
                gzip()
            }
            install(HttpTimeout) {
                connectTimeoutMillis = 1000
                socketTimeoutMillis = 1000
                requestTimeoutMillis = 1000
            }
        }

        val response = client.get("/test")
        println(response.body<String>())
    }

Other

Some issues related to digest authentication in 3.5.0

Structured concurrency is violated in WebRTC tests

3.5.0

released 18th May 2026

Client

CIO: Engine treats response header names case-sensitively and drops earlier repeated headers

https://youtrack.jetbrains.com/issue/KTOR-8614

Summary

CIO engine treats HTTP response header names case-sensitively, causing repeated headers with different casing to be ignored.

Affected Version

Ktor client: latest (also reproducible in earlier versions)
Engine: CIO

Steps to Reproduce

Server Response

HTTP/1.1 200 OK  
Content-Length: 0  
x-custom-header: Value2  
x-custom-header: Value3  
X-Custom-Header: Value1

Client Code

val client = HttpClient(CIO)

runBlocking {
val response = client.get("http://example.com/test")
println(response.headers.getAll("X-Custom-Header"))
}

Actual Behavior

Only the last header (X-Custom-Header: Value1) is retained. The previous two headers with lowercase x-custom-header are ignored.

// Output:
[Value1]

Expected Behavior

HTTP header names are case-insensitive per RFC 7230 §3.2. All values should be preserved regardless of case.

// Expected:
[Value2, Value3, Value1]

Or values should be accessible via case-insensitive lookups:

response.headers.getAll("X-Custom-Header") // [Value2, Value3, Value1]
response.headers.getAll("x-custom-header") // [Value2, Value3, Value1]

Additional Notes

If the response includes only headers with the same case (e.g., all lowercase), values are preserved correctly:

x-custom-header: Value2  
x-custom-header: Value3

→ Output:

[Value2, Value3]

This issue does not occur with the OkHttp engine.

Suspected root cause

The issue may originate in:

ktor-client/ktor-client-cio/common/src/io/ktor/client/engine/cio/utils.kt
Specifically in the extension function:

fun HttpHeadersMap.toMap(): Map<String, List<String>>

While HttpHeadersMap internally treats all keys in lowercase (ensuring case-insensitivity), the toMap() function appears to expose them using original casing, which introduces inconsistency and case-sensitive behavior at the public API level.

This contradicts the internal logic and breaks the expected contract for header retrieval in HttpResponse.

Impact

This breaks expected behavior for headers like:

Set-Cookie
X-Forwarded-For
Custom headers sent with different casing from proxies or backends

It may cause integrations to behave incorrectly or lose data depending on the header casing used by the server.

Streaming call not cancelled when exception is thrown from HttpStatement.execute/body

https://youtrack.jetbrains.com/issue/KTOR-9398

Description

Consider this snippet, which requests a notification for when a container is "not-running":

val client = HttpClient(...) // same behaviour with CIO, OkHttp, Java, and I suspect other engines. 
client
   .preparePost("http://127.0.0.1:2375/containers/my_container_name/wait") {
        parameter("condition", "not-running")
        timeout {
            // we could theoretically be waiting indefinitely for the container to be "not running"
            // so set the timeouts accordingly
            requestTimeoutMillis = HttpTimeoutConfig.INFINITE_TIMEOUT_MS
            socketTimeoutMillis = HttpTimeoutConfig.INFINITE_TIMEOUT_MS
        }
    }
    .execute { response ->
        // the response Headers are received immediately
        assert(response.status.value == 200)
        // But the body of the response may stream very VERY slowly.
        // Wouldn't we expect the below `throw` to cancel the call NOW?
        // (without waiting for the next piece of data to arrive)
        throw Throwable("does not close connection with streaming response, until another chunk/DATA frame arrives")
    }

The initial response headers are received immediately (regardless of whether the container is running or not). But the actual notification of when the container is "not running" is transferred as a single streamed frame in the body (chunked-encoded in HTTP/1.1; DATA frame in HTTP/2). This means there can be an arbitrary delay between receiving the request headers and receiving some data. But if, meanwhile, an exception is thrown in the execute block, then the call to execute suspends until a frame arrives, which could (theoratically) take forever.

Actual behaviour

The call blocks until a frame arrives, which could (theoratically) take forever.

Expected behaviour

The call is automatically cancelled, promptly returning control to the caller of execute

Cases where an exception may be thrown in `execute/body`'s block

using a check

.execute { response ->
    check(response.status.value == 200) { // can throw IllegalStateException
      "must be 200"
    }
    ...
}

using a flow operator that uses collectWhile (firstOrNull, transformWhile, etc.

val aFlow = flow {
    client.prepareGet("...").body { channel: ByteReadChannel ->
        while (true) {
            // imagine a line is sent by the server only every minute
            emit(channel.readLine()) // can throw `AbortFlowException` from `collectWhile`
        }
    }
}
aFlow.takeWhile { ... } // or any other operator calling `collectWhile`

Fix suggestion

In HttpResponse.cleanup, calling complete on the "call job" does indeed cancel the underlying request channels, but does not throw CancellationException in coroutines that are already suspended and awaiting content, thus leading to this behaviour.

While perhaps it would be possible to always call cancel, the snippet below would fix this bug for the cases given above, while keeping the current behaviour if nothing is thrown from block.

Note that the cancellation is the same as the one triggered in attachToUserJob .

public suspend fun <T> execute(block: suspend (response: HttpResponse) -> T): T = unwrapRequestTimeoutException {
    val response = fetchStreamingResponse()

    var cause: Throwable? = null
    try {
        ...
    } catch (t: Throwable) {
        cause = t
        throw t
    } finally {
        response.cleanup(cause)
    }
}

internal suspend fun HttpResponse.cleanup(cause: Throwable?) {
    val job = coroutineContext.job as CompletableJob

    job.apply {
        if (cause != null) {
            // same cancellation as in `attachToUserJob`
            cancel(kotlinx.coroutines.CancellationException(cause.message))
        } else {
            complete()
        }
        ...
        join()
    }
}

In a way, the fix is very similar to how emitAllImpl is implemented.

Comment on an existing issue

To avoid being flagged as duplicate to KTOR-2510, which has a similar title to this issue, let me make a couple of remarks about it:

it is wildly outdated;
it does not specify what should happen when an exception is thrown; it simply states that something used to hang.

Apache: body channel not cancelled when caller scope is cancelled

DNS configuration for the Apache5 client

DNS configuration for OkHttp client engine

Websockets: Unable to close session with a custom CloseReason

Content-Disposition additional parameters should be inside quotes

Darwin throws DarwinHttpRequestException instead of FrameTooBigException

Curl: backpressure implementation is never used

https://youtrack.jetbrains.com/issue/KTOR-9483

Background

Current runBlocking implementation accidentally provides backpressure by blocking the curl multi-handle thread inside runBlocking { writeFully() } — but this is the wrong mechanism, as it stalled all in-flight requests, not just the one that needed throttling.

Desired behavior

When the response ByteChannel buffer reaches CHANNEL_MAX_SIZE (1 MB), the curl engine should return WRITEFUNC_PAUSE from the write callback to pause the specific easy handle. When the consumer drains enough data, curl_easy_pause(CURLPAUSE_CONT) should resume it.

This is the correct curl backpressure mechanism, already used on the upload path (CurlRequestBodyData).

Design notes

The challenge is that onBodyChunkReceived is a synchronous C callback — it cannot suspend. Two approaches were explored:

Approach 1: availableForWrite property on ByteChannel

Add @InternalAPI val availableForWrite: Int to ByteChannel (class only, not the BufferedByteWriteChannel interface — no ABI breakage). The callback checks this before writing:

bodyChannel.writeBuffer.writeFully(buffer, 0L, chunkSize.toLong())
bodyChannel.flushWriteBuffer()
if (bodyChannel.availableForWrite > 0) return chunkSize.convert() // fast path, zero alloc

// slow path: buffer full
paused = true
scope.launch {
    bodyChannel.flush()  // suspends until drained
    paused = false
    onUnpause()
}
return chunkSize.convert()

Zero allocations on the fast path.

Approach 2: startCoroutineUninterceptedOrReturn on a reusable lambda

No ktor-io changes needed. Make the class implement Continuation<Unit> and store the flush lambda as a val (created once, captures only this):

private val awaitFreeSpace: suspend () -> Unit = { bodyChannel.flush() }

// In onBodyChunkReceived:
bodyChannel.writeBuffer.writeFully(buffer, 0L, chunkSize.toLong())
bodyChannel.flushWriteBuffer()
val outcome = awaitFreeSpace.startCoroutineUninterceptedOrReturn(this)
if (outcome === COROUTINE_SUSPENDED) paused = true
return chunkSize.convert()

One state machine allocation per chunk on the hot path (unavoidable without internal API). Combined with Approach 1's pre-check, the hot path becomes zero-alloc.

Notes

onUnpause infrastructure (easyHandlesToUnpause, unpauseEasyHandle) already exists in CurlMultiApiHandler for uploads — response bodies can reuse it
Darwin also lacks backpressure support (KTOR-9145)

Curl: Freeze when receiving large responses

A client call wrapped with `withTimeout` throws a generic CancellationException instead of TimeoutCancellationException

https://youtrack.jetbrains.com/issue/KTOR-9183

Description

When using withTimeout or withTimeoutOrNull, the specific TimeoutCancellationException can get lost, as Ktor throws a CancellationException instead.

Repro

These tests

class KtorTest {
    private val client = HttpClient()

    @Test
    fun withTimeoutOrNull() = runBlocking(Dispatchers.Default) {
        val response = withTimeoutOrNull(1.milliseconds) {
            client.get("https://ktor.io/")
        }
        assert(response == null) { "Expected a null value" }
    }

    @Test
    fun withTimeout() = runBlocking(Dispatchers.Default) {
        try {
            withTimeout(1.milliseconds) {
                client.get("https://ktor.io/")
            }
            fail("Expected a timeout")
        } catch (e: TimeoutCancellationException) {
        }
    }
}

fail with

java.util.concurrent.CancellationException: Timed out waiting for 1 ms
	at io.ktor.client.engine.UtilsKt$attachToUserJob$cleanupHandler$1.invoke(Utils.kt:108)
	at io.ktor.client.engine.UtilsKt$attachToUserJob$cleanupHandler$1.invoke(Utils.kt:106)
	at kotlinx.coroutines.InvokeOnCancelling.invoke(JobSupport.kt:1571)
	at kotlinx.coroutines.JobSupport.invokeOnCompletionInternal$kotlinx_coroutines_core(JobSupport.kt:500)
	at kotlinx.coroutines.JobSupport.invokeOnCompletion(JobSupport.kt:452)
	at kotlinx.coroutines.Job$DefaultImpls.invokeOnCompletion$default(Job.kt:328)
	at io.ktor.client.engine.HttpClientEngineKt.createCallContext(HttpClientEngine.kt:242)
	at io.ktor.client.engine.HttpClientEngine.executeWithinCallContext(HttpClientEngine.kt:175)
	at io.ktor.client.engine.HttpClientEngine.access$executeWithinCallContext(HttpClientEngine.kt:36)
	at io.ktor.client.engine.HttpClientEngine$install$1.invokeSuspend(HttpClientEngine.kt:154)
	at io.ktor.client.engine.HttpClientEngine$install$1.invoke(HttpClientEngine.kt)
	at io.ktor.client.engine.HttpClientEngine$install$1.invoke(HttpClientEngine.kt)
	at io.ktor.util.pipeline.DebugPipelineContext.proceedLoop(DebugPipelineContext.kt:79)
	at io.ktor.util.pipeline.DebugPipelineContext.proceed(DebugPipelineContext.kt:57)
	at io.ktor.util.pipeline.DebugPipelineContext.execute$ktor_utils(DebugPipelineContext.kt:63)
	at io.ktor.util.pipeline.Pipeline.execute(Pipeline.kt:92)
	at io.ktor.client.plugins.HttpSend$DefaultSender.execute(HttpSend.kt:137)
	at io.ktor.client.plugins.api.Send$Sender.proceed(CommonHooks.kt:47)
	at io.ktor.client.plugins.HttpRedirectKt$HttpRedirect$2$1.invokeSuspend(HttpRedirect.kt:112)
	at io.ktor.client.plugins.HttpRedirectKt$HttpRedirect$2$1.invoke(HttpRedirect.kt)
	at io.ktor.client.plugins.HttpRedirectKt$HttpRedirect$2$1.invoke(HttpRedirect.kt)
	at io.ktor.client.plugins.api.Send$install$1.invokeSuspend(CommonHooks.kt:52)
	at io.ktor.client.plugins.api.Send$install$1.invoke(CommonHooks.kt)
	at io.ktor.client.plugins.api.Send$install$1.invoke(CommonHooks.kt)
	at io.ktor.client.plugins.HttpSend$InterceptedSender.execute(HttpSend.kt:115)
	at io.ktor.client.plugins.api.Send$Sender.proceed(CommonHooks.kt:47)
	at io.ktor.client.plugins.HttpCallValidatorKt$HttpCallValidator$2$2.invokeSuspend(HttpCallValidator.kt:128)
	at io.ktor.client.plugins.HttpCallValidatorKt$HttpCallValidator$2$2.invoke(HttpCallValidator.kt)
	at io.ktor.client.plugins.HttpCallValidatorKt$HttpCallValidator$2$2.invoke(HttpCallValidator.kt)
	at io.ktor.client.plugins.api.Send$install$1.invokeSuspend(CommonHooks.kt:52)
	at io.ktor.client.plugins.api.Send$install$1.invoke(CommonHooks.kt)
	at io.ktor.client.plugins.api.Send$install$1.invoke(CommonHooks.kt)
	at io.ktor.client.plugins.HttpSend$InterceptedSender.execute(HttpSend.kt:115)
	at io.ktor.client.plugins.HttpSend$Plugin$install$1.invokeSuspend(HttpSend.kt:103)
	at io.ktor.client.plugins.HttpSend$Plugin$install$1.invoke(HttpSend.kt)
	at io.ktor.client.plugins.HttpSend$Plugin$install$1.invoke(HttpSend.kt)
	at io.ktor.util.pipeline.DebugPipelineContext.proceedLoop(DebugPipelineContext.kt:79)
	at io.ktor.util.pipeline.DebugPipelineContext.proceed(DebugPipelineContext.kt:57)
	at io.ktor.client.plugins.RequestError$install$1.invokeSuspend(HttpCallValidator.kt:150)
	at io.ktor.client.plugins.RequestError$install$1.invoke(HttpCallValidator.kt)
	at io.ktor.client.plugins.RequestError$install$1.invoke(HttpCallValidator.kt)
	at io.ktor.util.pipeline.DebugPipelineContext.proceedLoop(DebugPipelineContext.kt:79)
	at io.ktor.util.pipeline.DebugPipelineContext.proceed(DebugPipelineContext.kt:57)
	at io.ktor.client.plugins.SetupRequestContext$install$1.invokeSuspend$proceed(HttpRequestLifecycle.kt:42)
	at io.ktor.client.plugins.SetupRequestContext$install$1.access$invokeSuspend$proceed(HttpRequestLifecycle.kt)
	at io.ktor.client.plugins.SetupRequestContext$install$1$1.invoke(HttpRequestLifecycle.kt:42)
	at io.ktor.client.plugins.SetupRequestContext$install$1$1.invoke(HttpRequestLifecycle.kt:42)
	at io.ktor.client.plugins.HttpRequestLifecycleKt$HttpRequestLifecycle$1$1.invokeSuspend(HttpRequestLifecycle.kt:29)
	at io.ktor.client.plugins.HttpRequestLifecycleKt$HttpRequestLifecycle$1$1.invoke(HttpRequestLifecycle.kt)
	at io.ktor.client.plugins.HttpRequestLifecycleKt$HttpRequestLifecycle$1$1.invoke(HttpRequestLifecycle.kt)
	at io.ktor.client.plugins.SetupRequestContext$install$1.invokeSuspend(HttpRequestLifecycle.kt:42)
	at io.ktor.client.plugins.SetupRequestContext$install$1.invoke(HttpRequestLifecycle.kt)
	at io.ktor.client.plugins.SetupRequestContext$install$1.invoke(HttpRequestLifecycle.kt)
	at io.ktor.util.pipeline.DebugPipelineContext.proceedLoop(DebugPipelineContext.kt:79)
	at io.ktor.util.pipeline.DebugPipelineContext.proceed(DebugPipelineContext.kt:57)
	at io.ktor.util.pipeline.DebugPipelineContext.execute$ktor_utils(DebugPipelineContext.kt:63)
	at io.ktor.util.pipeline.Pipeline.execute(Pipeline.kt:92)
	at io.ktor.client.HttpClient.execute$ktor_client_core(HttpClient.kt:1415)
	at io.ktor.client.statement.HttpStatement.fetchResponse(HttpStatement.kt:163)
	at io.ktor.client.statement.HttpStatement.execute(HttpStatement.kt:77)
	at KtorTest$withTimeoutOrNull$1$response$1.invokeSuspend(KtorTest.kt:46)
	at KtorTest$withTimeoutOrNull$1$response$1.invoke(KtorTest.kt)
	at KtorTest$withTimeoutOrNull$1$response$1.invoke(KtorTest.kt)
	at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndspatched(Undispatched.kt:66)
	at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturnIgnoreTimeout(Undispatched.kt:50)
	at kotlinx.coroutines.TimeoutKt.setupTimeout(Timeout.kt:149)
	at kotlinx.coroutines.TimeoutKt.withTimeoutOrNull(Timeout.kt:105)
	at kotlinx.coroutines.TimeoutKt.withTimeoutOrNull-KLykuaI(Timeout.kt:137)
	at KtorTest$withTimeoutOrNull$1.invokeSuspend(KtorTest.kt:17)
	at _COROUTINE._BOUNDARY._(CoroutineDebugging.kt:42)
	at io.ktor.client.engine.HttpClientEngine.executeWithinCallContext(HttpClientEngine.kt:184)
	at io.ktor.client.engine.HttpClientEngine$install$1.invokeSuspend(HttpClientEngine.kt:154)
	at io.ktor.util.pipeline.DebugPipelineContext.proceedLoop(DebugPipelineContext.kt:79)
	at io.ktor.client.plugins.HttpSend$DefaultSender.execute(HttpSend.kt:137)
	at io.ktor.client.plugins.HttpRedirectKt$HttpRedirect$2$1.invokeSuspend(HttpRedirect.kt:112)
	at io.ktor.client.plugins.api.Send$install$1.invokeSuspend(CommonHooks.kt:52)
	at io.ktor.client.plugins.HttpCallValidatorKt$HttpCallValidator$2$2.invokeSuspend(HttpCallValidator.kt:128)
	at io.ktor.client.plugins.api.Send$install$1.invokeSuspend(CommonHooks.kt:52)
	at io.ktor.client.plugins.HttpSend$Plugin$install$1.invokeSuspend(HttpSend.kt:103)
	at io.ktor.util.pipeline.DebugPipelineContext.proceedLoop(DebugPipelineContext.kt:79)
	at io.ktor.client.plugins.RequestError$install$1.invokeSuspend(HttpCallValidator.kt:150)
	at io.ktor.util.pipeline.DebugPipelineContext.proceedLoop(DebugPipelineContext.kt:79)
	at io.ktor.client.plugins.HttpRequestLifecycleKt$HttpRequestLifecycle$1$1.invokeSuspend(HttpRequestLifecycle.kt:29)
	at io.ktor.client.plugins.SetupRequestContext$install$1.invokeSuspend(HttpRequestLifecycle.kt:42)
	at io.ktor.util.pipeline.DebugPipelineContext.proceedLoop(DebugPipelineContext.kt:79)
	at io.ktor.client.HttpClient.execute$ktor_client_core(HttpClient.kt:1415)
	at io.ktor.client.statement.HttpStatement.fetchResponse(HttpStatement.kt:163)
	at KtorTest$withTimeoutOrNull$1$response$1.invokeSuspend(KtorTest.kt:46)
	at kotlinx.coroutines.TimeoutKt.withTimeoutOrNull(Timeout.kt:102)
	at KtorTest$withTimeoutOrNull$1.invokeSuspend(KtorTest.kt:17)
Caused by: java.util.concurrent.CancellationException: Timed out waiting for 1 ms
	at io.ktor.client.engine.UtilsKt$attachToUserJob$cleanupHandler$1.invoke(Utils.kt:108)
	at io.ktor.client.engine.UtilsKt$attachToUserJob$cleanupHandler$1.invoke(Utils.kt:106)
	at kotlinx.coroutines.InvokeOnCancelling.invoke(JobSupport.kt:1571)
	at kotlinx.coroutines.JobSupport.invokeOnCompletionInternal$kotlinx_coroutines_core(JobSupport.kt:500)
	at kotlinx.coroutines.JobSupport.invokeOnCompletion(JobSupport.kt:452)
	at kotlinx.coroutines.Job$DefaultImpls.invokeOnCompletion$default(Job.kt:328)
	at io.ktor.client.engine.HttpClientEngineKt.createCallContext(HttpClientEngine.kt:242)
	at io.ktor.client.engine.HttpClientEngine.executeWithinCallContext(HttpClientEngine.kt:175)
	at io.ktor.client.engine.HttpClientEngine.access$executeWithinCallContext(HttpClientEngine.kt:36)
	at io.ktor.client.engine.HttpClientEngine$install$1.invokeSuspend(HttpClientEngine.kt:154)
	at io.ktor.client.engine.HttpClientEngine$install$1.invoke(HttpClientEngine.kt)
	at io.ktor.client.engine.HttpClientEngine$install$1.invoke(HttpClientEngine.kt)
	at io.ktor.util.pipeline.DebugPipelineContext.proceedLoop(DebugPipelineContext.kt:79)
	at io.ktor.util.pipeline.DebugPipelineContext.proceed(DebugPipelineContext.kt:57)
	at io.ktor.util.pipeline.DebugPipelineContext.execute$ktor_utils(DebugPipelineContext.kt:63)
	at io.ktor.util.pipeline.Pipeline.execute(Pipeline.kt:92)
	at io.ktor.client.plugins.HttpSend$DefaultSender.execute(HttpSend.kt:137)
	at io.ktor.client.plugins.api.Send$Sender.proceed(CommonHooks.kt:47)
	at io.ktor.client.plugins.HttpRedirectKt$HttpRedirect$2$1.invokeSuspend(HttpRedirect.kt:112)
	at io.ktor.client.plugins.HttpRedirectKt$HttpRedirect$2$1.invoke(HttpRedirect.kt)
	at io.ktor.client.plugins.HttpRedirectKt$HttpRedirect$2$1.invoke(HttpRedirect.kt)
	at io.ktor.client.plugins.api.Send$install$1.invokeSuspend(CommonHooks.kt:52)
	at io.ktor.client.plugins.api.Send$install$1.invoke(CommonHooks.kt)
	at io.ktor.client.plugins.api.Send$install$1.invoke(CommonHooks.kt)
	at io.ktor.client.plugins.HttpSend$InterceptedSender.execute(HttpSend.kt:115)
	at io.ktor.client.plugins.api.Send$Sender.proceed(CommonHooks.kt:47)
	at io.ktor.client.plugins.HttpCallValidatorKt$HttpCallValidator$2$2.invokeSuspend(HttpCallValidator.kt:128)
	at io.ktor.client.plugins.HttpCallValidatorKt$HttpCallValidator$2$2.invoke(HttpCallValidator.kt)
	at io.ktor.client.plugins.HttpCallValidatorKt$HttpCallValidator$2$2.invoke(HttpCallValidator.kt)
	at io.ktor.client.plugins.api.Send$install$1.invokeSuspend(CommonHooks.kt:52)
	at io.ktor.client.plugins.api.Send$install$1.invoke(CommonHooks.kt)
	at io.ktor.client.plugins.api.Send$install$1.invoke(CommonHooks.kt)
	at io.ktor.client.plugins.HttpSend$InterceptedSender.execute(HttpSend.kt:115)
	at io.ktor.client.plugins.HttpSend$Plugin$install$1.invokeSuspend(HttpSend.kt:103)
	at io.ktor.client.plugins.HttpSend$Plugin$install$1.invoke(HttpSend.kt)
	at io.ktor.client.plugins.HttpSend$Plugin$install$1.invoke(HttpSend.kt)
	at io.ktor.util.pipeline.DebugPipelineContext.proceedLoop(DebugPipelineContext.kt:79)
	at io.ktor.util.pipeline.DebugPipelineContext.proceed(DebugPipelineContext.kt:57)
	at io.ktor.client.plugins.RequestError$install$1.invokeSuspend(HttpCallValidator.kt:150)
	at io.ktor.client.plugins.RequestError$install$1.invoke(HttpCallValidator.kt)
	at io.ktor.client.plugins.RequestError$install$1.invoke(HttpCallValidator.kt)
	at io.ktor.util.pipeline.DebugPipelineContext.proceedLoop(DebugPipelineContext.kt:79)
	at io.ktor.util.pipeline.DebugPipelineContext.proceed(DebugPipelineContext.kt:57)
	at io.ktor.client.plugins.SetupRequestContext$install$1.invokeSuspend$proceed(HttpRequestLifecycle.kt:42)
	at io.ktor.client.plugins.SetupRequestContext$install$1.access$invokeSuspend$proceed(HttpRequestLifecycle.kt)
	at io.ktor.client.plugins.SetupRequestContext$install$1$1.invoke(HttpRequestLifecycle.kt:42)
	at io.ktor.client.plugins.SetupRequestContext$install$1$1.invoke(HttpRequestLifecycle.kt:42)
	at io.ktor.client.plugins.HttpRequestLifecycleKt$HttpRequestLifecycle$1$1.invokeSuspend(HttpRequestLifecycle.kt:29)
	at io.ktor.client.plugins.HttpRequestLifecycleKt$HttpRequestLifecycle$1$1.invoke(HttpRequestLifecycle.kt)
	at io.ktor.client.plugins.HttpRequestLifecycleKt$HttpRequestLifecycle$1$1.invoke(HttpRequestLifecycle.kt)
	at io.ktor.client.plugins.SetupRequestContext$install$1.invokeSuspend(HttpRequestLifecycle.kt:42)
	at io.ktor.client.plugins.SetupRequestContext$install$1.invoke(HttpRequestLifecycle.kt)
	at io.ktor.client.plugins.SetupRequestContext$install$1.invoke(HttpRequestLifecycle.kt)
	at io.ktor.util.pipeline.DebugPipelineContext.proceedLoop(DebugPipelineContext.kt:79)
	at io.ktor.util.pipeline.DebugPipelineContext.proceed(DebugPipelineContext.kt:57)
	at io.ktor.util.pipeline.DebugPipelineContext.execute$ktor_utils(DebugPipelineContext.kt:63)
	at io.ktor.util.pipeline.Pipeline.execute(Pipeline.kt:92)
	at io.ktor.client.HttpClient.execute$ktor_client_core(HttpClient.kt:1415)
	at io.ktor.client.statement.HttpStatement.fetchResponse(HttpStatement.kt:163)
	at io.ktor.client.statement.HttpStatement.execute(HttpStatement.kt:77)
	at KtorTest$withTimeoutOrNull$1$response$1.invokeSuspend(KtorTest.kt:46)
	at KtorTest$withTimeoutOrNull$1$response$1.invoke(KtorTest.kt)
	at KtorTest$withTimeoutOrNull$1$response$1.invoke(KtorTest.kt)
	at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndspatched(Undispatched.kt:66)
	at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturnIgnoreTimeout(Undispatched.kt:50)
	at kotlinx.coroutines.TimeoutKt.setupTimeout(Timeout.kt:149)
	at kotlinx.coroutines.TimeoutKt.withTimeoutOrNull(Timeout.kt:105)
	at kotlinx.coroutines.TimeoutKt.withTimeoutOrNull-KLykuaI(Timeout.kt:137)
	at KtorTest$withTimeoutOrNull$1.invokeSuspend(KtorTest.kt:17)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:34)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:100)
	at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.kt:124)
	at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:89)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:586)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:820)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:717)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:704)

Note

They run fine on Ktor 2.3.13
When running the whole test class instead of individual tests, only 1 test fails
Increasing the timeout can make the tests pass

Kotlin/JS: ktor-ktor-client-core.mjs is incompatible with Vite: toRaw naming conflict

HttpClient: cancelling ByteReadChannel body does not propagate to engine

Curl: body channel not cancelled when caller scope is cancelled

Curl: CancelWebSocket task may cancel a new HTTP request due to easy handle pointer reuse

https://youtrack.jetbrains.com/issue/KTOR-9540

Problem

testHttpRequestAfterWebSocketClose fails for the Curl engine on Windows:

kotlin.AssertionError: Test failed for engine 'native:Curl' with:
  kotlin.coroutines.cancellation.CancellationException: WebSocket session closed
  at io.ktor.client.engine.curl.CurlProcessor.$drainTaskQueueCOROUTINE$4.invokeSuspend#internal

Root cause

Introduced by #5469 (commit 5643569708b7a483e52bac1166b86603c99ad83f), which fixed a WebSocket handle leak by enqueuing a CancelWebSocket(easyHandle) task whenever a WebSocket session closes.

The fix correctly guards against the cancelled handle already being gone from activeHandles (?: continue), but misses the ABA pointer-reuse case:

WebSocket TCP connection closes naturally → curl_multi_info_read fires → handleCompleted removes the handle from activeHandles and calls curl_easy_cleanup, freeing the pointer.
A new HTTP request arrives → curl_easy_init() reuses the same pointer address → added to activeHandles.
CancelWebSocket(oldHandle) is dequeued → activeHandles.remove(oldHandle) finds the new HTTP request at that address → cancels it with CancellationException("WebSocket session closed").

The bug only manifests for WebSockets because CurlWebSocketSession.close() always enqueues a cancellation (even on clean close), whereas regular HTTP request cancellation only fires on error.

Fix

Carry CurlWebSocketResponseBody in CancelWebSocket instead of the raw EasyHandle. In CurlMultiApiHandler.cancelWebSocket(), verify identity before acting:

fun cancelWebSocket(websocket: CurlWebSocketResponseBody, cause: Throwable) {
    val easyHandle = websocket.easyHandle
    val handler = activeHandles[easyHandle] ?: return
    if (handler.responseWrapper.get() !== websocket) return  // ABA check
    activeHandles.remove(easyHandle)
    processCancelledEasyHandle(easyHandle, cause)
    handler.responseCompletable.completeExceptionally(cause)
    handler.dispose()
}

If curl_easy_init reused the pointer for a new request, handler.responseWrapper.get() returns the new request's response body, which is not the same object as websocket, so we return early and the new request is left untouched.

Curl: WebSocket bearer token refresh fails due to stale native handle reuse

OkHttp: Websockets pinging doesn't work

Jetty, Java: Custom Host header doesn't override the default value

Compiler Plugin

OpenAPI code inference misses property delegation

Core

Make ktor-network compatible with ES modules for nodejs

Docs

Documentation for Jetty Jakarta: Provide an easy way to disable SNI hostname validation

Documentation for Sessions: Add a way to create a user session shared for all user devices or look up sessions of the same user

Documentation for Custom SSE heartbeat function

Add a note for java default version in "Heroku"

Add code sample projects for "I/O Interoperability"

Beginner tutorials are out-of-date with the project generator

Update the Integrate a database tutorial

Update the Create a website tutorial

Update the Create a WebSocket application tutorial

Clarify that default url path must contain a trailing slash

Update the Handle requests and generate responses tutorial

Update generated project in the RESTful API tutorial

Documentation for DNS configuration for the Apache5 client

Documentation for DNS configuration for OkHttp client engine

Documentation for Add an option to not resend the session cookie if the session data wasn't changed.

Documentation for Provide parameter validation convenience functions

Documentation for OpenAPI: Support prefixItems in JsonSchema for tuple type definitions

Change the year format used in "Logging"

Documentation for Support getAs from the root ApplicationConfig

Infrastructure

JS: Make ES2015 the default target for tests

Upgrade to Kotlin 2.3.21

Network

Flaky UnixSockets on Windows: WSAEOPNOTSUPP from bind()

Server

Plugin onCallReceive/transformBody is not called for receive<ByteArray>()

https://youtrack.jetbrains.com/issue/KTOR-6683

Hi folks,

I recently fiddled around with a plugin to transform request bytes in a ktor application.

I setup a minimum example here:

package org.example

import io.ktor.client.HttpClient
import io.ktor.client.engine.apache.Apache
import io.ktor.client.request.post
import io.ktor.client.request.setBody
import io.ktor.http.ContentType
import io.ktor.http.contentType
import io.ktor.server.application.Application
import io.ktor.server.application.call
import io.ktor.server.application.createApplicationPlugin
import io.ktor.server.application.install
import io.ktor.server.engine.embeddedServer
import io.ktor.server.jetty.jakarta.Jetty
import io.ktor.server.request.receive
import io.ktor.server.routing.post
import io.ktor.server.routing.routing
import kotlinx.coroutines.runBlocking

fun Application.module() {
    install(createApplicationPlugin(name = "SomeApplicationPlugin") {
        onCallReceive { call ->
            transformBody {
                println("onCallReceive")
                it
            }
        }
    })
    configureRouting()
}

fun Application.configureRouting() {
    routing {
        post("/") {
            call.receive<ByteArray>()
        }
    }
}

fun main(args: Array<String>) {
    runBlocking {
        embeddedServer(Jetty, port = 8080, host = "127.0.0.1", module = Application::module).start()
        val client = HttpClient(Apache)
        client.post("http://127.0.0.1:8080") {
            contentType(ContentType.Text.Plain)
            setBody("This is a test")
        }
    }
}

Why is call.receive<ByteArray>() not causing the plugin to call transformBody()? However, when I change it to call.receive<String>(), onCallReceive is printed to stdout. This at least looks to me like unexpected, if not buggy behavior. I would like to understand why that happens. And I think it would be valuable to add that information to the docs. I was not able to find any hints in that regard.

Thanks, and keep up with the great work!

-David