Changelog 3.6 version

3.6.0

released 18th September 2026

Client

Digest Auth: NullPointerException when the server does not expect Digest auth

Server

JWTAuthenticationProvider silently swallows exceptions

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

When usingJwkProvider sometimes due to network or configuration the provider on start-up.
The Jwt plugin swallows these exceptions without any logging, unless TRACE level is enabled.

When this occurs false negatives start occurring, and this can be incredibly confusing if TRACE level logging is not enabled.

2026-01-15 15:25:24.485 [lettuce-nioEventLoop-4-1] TRACE io.ktor.auth.jwt - Failed to get JWK
com.auth0.jwk.NetworkException: Cannot obtain jwks from url http://localhost:8000/realms/foodies-keycloak/protocol/openid-connect/certs/.well-known/jwks.json
	at com.auth0.jwk.UrlJwkProvider.getJwks(UrlJwkProvider.java:144)
	at com.auth0.jwk.UrlJwkProvider.getAll(UrlJwkProvider.java:150)
	at com.auth0.jwk.UrlJwkProvider.getCachedJwks(UrlJwkProvider.java:172)
	at com.auth0.jwk.UrlJwkProvider.findKey(UrlJwkProvider.java:181)
	at com.auth0.jwk.UrlJwkProvider.get(UrlJwkProvider.java:213)
	at com.auth0.jwk.RateLimitedJwkProvider.get(RateLimitedJwkProvider.java:28)
	at com.auth0.jwk.GuavaCachedJwkProvider.lambda$get$0(GuavaCachedJwkProvider.java:62)
	at com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4927)
	at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3571)
	at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2313)
	at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2190)
	at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2080)
	at com.google.common.cache.LocalCache.get(LocalCache.java:4012)
	at com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4922)
	at com.auth0.jwk.GuavaCachedJwkProvider.get(GuavaCachedJwkProvider.java:62)
	at io.ktor.server.auth.jwt.JWTUtilsKt.getVerifier(JWTUtils.kt:55)
	at io.ktor.server.auth.jwt.JWTAuthenticationProvider$Config.verifier$lambda$2(JWTAuth.kt:312)
	at io.ktor.server.auth.jwt.JWTAuthenticationProvider.onAuthenticate(JWTAuth.kt:197)
	at io.ktor.server.auth.AuthenticationInterceptorsKt$AuthenticationInterceptors$2$2.invokeSuspend(AuthenticationInterceptors.kt:135)
	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)
	at io.ktor.server.application.ApplicationPluginKt$addAllInterceptors$1$1$1.invokeSuspend(ApplicationPlugin.kt:209)
	at io.ktor.server.application.ApplicationPluginKt$addAllInterceptors$1$1$1.invoke(ApplicationPlugin.kt)
	at io.ktor.server.application.ApplicationPluginKt$addAllInterceptors$1$1$1.invoke(ApplicationPlugin.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.server.routing.RoutingRoot$executeResult$$inlined$execute$1.invokeSuspend(Pipeline.kt:510)
	at io.ktor.server.routing.RoutingRoot$executeResult$$inlined$execute$1.invoke(Pipeline.kt)
	at io.ktor.server.routing.RoutingRoot$executeResult$$inlined$execute$1.invoke(Pipeline.kt)
	at io.ktor.util.debug.ContextUtilsKt.initContextInDebugMode(ContextUtils.kt:19)
	at io.ktor.server.routing.RoutingRoot.executeResult(RoutingRoot.kt:212)
	at io.ktor.server.routing.RoutingRoot.interceptor(RoutingRoot.kt:71)
	at io.ktor.server.routing.RoutingRoot$Plugin$install$1.invokeSuspend(RoutingRoot.kt:157)
	at io.ktor.server.routing.RoutingRoot$Plugin$install$1.invoke(RoutingRoot.kt)
	at io.ktor.server.routing.RoutingRoot$Plugin$install$1.invoke(RoutingRoot.kt)
	at io.ktor.util.pipeline.DebugPipelineContext.proceedLoop(DebugPipelineContext.kt:79)
	at io.ktor.util.pipeline.DebugPipelineContext.access$proceedLoop(DebugPipelineContext.kt:16)
	at io.ktor.util.pipeline.DebugPipelineContext$proceedLoop$1.invokeSuspend(DebugPipelineContext.kt)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:34)
	at io.ktor.server.application.ClassLoaderAwareContinuationInterceptor$interceptContinuation$1.resumeWith(ApplicationEnvironment.kt:79)
	at kotlinx.coroutines.DispatchedTaskKt.resume(DispatchedTask.kt:163)
	at kotlinx.coroutines.DispatchedTaskKt.dispatch(DispatchedTask.kt:152)
	at kotlinx.coroutines.CancellableContinuationImpl.dispatchResume(CancellableContinuationImpl.kt:470)
	at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl$kotlinx_coroutines_core(CancellableContinuationImpl.kt:504)
	at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl$kotlinx_coroutines_core$default(CancellableContinuationImpl.kt:493)
	at kotlinx.coroutines.CancellableContinuationImpl.resumeWith(CancellableContinuationImpl.kt:359)
	at kotlinx.coroutines.reactive.AwaitKt$awaitOne$2$1.onNext(Await.kt:238)
	at reactor.core.publisher.StrictSubscriber.onNext(StrictSubscriber.java:89)
	at reactor.core.publisher.MonoNext$NextSubscriber.onNext(MonoNext.java:82)
	at reactor.core.publisher.MonoNext$NextSubscriber.onNext(MonoNext.java:82)
	at io.lettuce.core.RedisPublisher$ImmediateSubscriber.onNext(RedisPublisher.java:895)
	at io.lettuce.core.RedisPublisher$RedisSubscription.onNext(RedisPublisher.java:295)
	at io.lettuce.core.RedisPublisher$SubscriptionCommand.doOnComplete(RedisPublisher.java:782)
	at io.lettuce.core.protocol.CommandWrapper.complete(CommandWrapper.java:69)
	at io.lettuce.core.protocol.CommandHandler.complete(CommandHandler.java:769)
	at io.lettuce.core.protocol.CommandHandler.decode(CommandHandler.java:704)
	at io.lettuce.core.protocol.CommandHandler.channelRead(CommandHandler.java:621)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:354)
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1429)
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:918)
	at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:168)
	at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.handle(AbstractNioChannel.java:445)
	at io.netty.channel.nio.NioIoHandler$DefaultNioRegistration.handle(NioIoHandler.java:388)
	at io.netty.channel.nio.NioIoHandler.processSelectedKey(NioIoHandler.java:596)
	at io.netty.channel.nio.NioIoHandler.processSelectedKeysOptimized(NioIoHandler.java:571)
	at io.netty.channel.nio.NioIoHandler.processSelectedKeys(NioIoHandler.java:512)
	at io.netty.channel.nio.NioIoHandler.run(NioIoHandler.java:484)
	at io.netty.channel.SingleThreadIoEventLoop.runIo(SingleThreadIoEventLoop.java:225)
	at io.netty.channel.SingleThreadIoEventLoop.run(SingleThreadIoEventLoop.java:196)
	at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:1193)
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: java.io.FileNotFoundException: http://localhost:8000/realms/foodies-keycloak/protocol/openid-connect/certs/.well-known/jwks.json
	at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:2023)
	at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1618)
	at com.auth0.jwk.UrlJwkProvider.getJwks(UrlJwkProvider.java:140)
	... 77 common frames omitted

OpenID Connect (OAuth2) auto-discover & configuration

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

Similar to https://youtrack.jetbrains.com/issue/KTOR-8595/Auth-JWK-Support-auto-discover, OpenID Connect OAuth2 flows can automatically be configured through auto-discovery granted the following information is provided:

clientId
clientSecret
issuer

Based on that, the current OAuth2 configuration could be done automatically (generated by Gemini 2.5 Pro). This snippet omits quite a lot of overloads to parameterise the actual underlying config.

import io.ktor.server.application.*
import io.ktor.server.auth.*
import io.ktor.server.routing.*
import io.ktor.client.HttpClient
import io.ktor.client.engine.cio.CIO
import io.ktor.client.call.*
import io.ktor.client.request.*
import kotlinx.serialization.json.Json
import kotlinx.serialization.Serializable

// Define a simplified data class for the discovery document (only relevant fields)
@Serializable
data class OpenIdConfiguration(
    val issuer: String,
    val authorization_endpoint: String,
    val token_endpoint: String,
    val jwks_uri: String
)

fun Application.configureOpenIdConnect(
    issuer: String,
    clientId: String? = null,
    clientSecret: String? = null,
    scopes: List<String> = listOf("openid"),
    callback: suspend RoutingContext.() -> Unit
) {
    val discoveryUrl = "$issuer/.well-known/openid-configuration"
    val clientId = clientId ?: environment.config.property("oauth.clientId").getString()
    val clientSecret = clientSecret ?: environment.config.property("oauth.clientSecret").getString()

    val httpClient = HttpClient(CIO)

    // In a real application, you'd want to cache this or load it once at startup
    // and handle potential network errors gracefully.
    val openIdConfig: OpenIdConfiguration =
         runBlocking { // Use runBlocking only for setup, not in production code generally
            httpClient.get(discoveryUrl).body()
        }

    install(Authentication) {
        oauth("auth-oauth-openid") {
            urlProvider = { redirectUrl("/oauth/callback") } // Your callback URL
            providerLookup = {
                OAuthServerSettings.OAuth2ServerSettings(
                    name = "YourOpenIDProvider",
                    authorizeUrl = openIdConfig.authorization_endpoint,
                    accessTokenUrl = openIdConfig.token_endpoint,
                    clientId = clientId,
                    clientSecret = clientSecret,
                    defaultScopes = scopes,
                    // You might also need to configure the request method for token endpoint (e.g., HttpMethod.Post)
                   // parameterise additional configuration
                )
            }
            client = httpClient
        }
    }

    routing {
        authenticate("auth-oauth-openid") {
            get("/login") { }
            get("/oauth/callback", callback)
        }
    }
}

// Helper function for redirect URL (replace with your actual domain and port)
fun ApplicationCall.redirectUrl(path: String): String {
    val protocol = request.origin.scheme
    val host = request.origin.host
    val port = request.origin.port
    return "$protocol://$host:$port$path"
}

CIO on Kotlin/Native collapses above ~50 connections: HttpHeadersMap pools contend on an allocating SynchronizedObject

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

Type: Bug · Subsystem: Server. Engine. CIO · Affected versions: 3.5.2 (and earlier 3.x)

Summary

On Kotlin/Native every parsed HTTP request takes two process-wide locks at least twice each, and the lock implementation allocates an object on every failed attempt, so the cost of an acquisition grows with the number of threads contending. Past about fifty connections the server does not slow down, it collapses: at 200 connections it serves 7 082 of the 60 000 requests offered with a p99 of 1.5 s, on 3.7 cores. The same binary with one file changed serves 60 053 with a p99 of 8.8 ms on 2.1 cores.

Environment

Kotlin 2.4.10 linuxX64 release binaries, Ktor 3.5.2 (ktor-server-cio, content negotiation, kotlinx-serialization), Ubuntu 26.04, 4 cores. Subject and load generator on separate hosts over a private link, k6, 30 s per run, arms rotated, twelve runs per arm, memory bounded by a cgroup.

What happens

HttpHeadersMap keeps its storage in two process-wide pools (ktor-http-cio/common/src/io/ktor/http/cio/HttpHeadersMap.kt):

private val IntArrayPool: DefaultPool<IntArray> = object : DefaultPool<IntArray>(1000) { ... }
private val HeadersDataPool: DefaultPool<HeadersData> = object : DefaultPool<HeadersData>(1000) { ... }

and on Kotlin/Native DefaultPool is a mutableListOf behind one SynchronizedObject, taken on every borrow and every recycle (ktor-io/posix/src/io/ktor/utils/io/pool/DefaultPool.posix.kt).

That SynchronizedObject (ktor-io/posix/src/io/ktor/utils/io/locks/Synchronized.kt) is a CAS loop over an AtomicReference<LockState> which allocates a LockState on every attempt and writes a heap reference on every attempt. A lost CAS is not a cheap retry. On the JVM the class is erased and synchronized becomes a monitor, so none of this is visible there.

The pools are not the only user of that lock. In the modules a native server links it is also ByteChannel.flushBufferMutex (ktor-io, 3 sites), every operation of ConcurrentMap (ktor-utils/posix, 17 sites — get, size and containsKey included, and Attributes is built on it), and DatagramSendChannel (ktor-network). Fixing the lock fixes all four; fixing the pool fixes one.

Evidence

perf, five runs: 32–73 % of all CPU is inside SynchronizedObject#lock, and the share is monotone with the damage. The collector's own functions are at 1–2 %.
gdb, three thread apply all bt snapshots under load: all 211 frames inside that function have the same two callers — DefaultPool#borrow from HttpHeadersMap#<init>, and DefaultPool#recycle from HttpHeadersMap#release and .resize.
A ladder of five servers on the same stand: ktor-network raw sockets with no ktor-server-core goes slow in 0 of 12 runs; adding the CIO parser makes it 9 of 12. The step where the slow state appears is the step where these pools appear.
The rate follows concurrency, not load. At the same 2 000 rps offered: 12 connections 0 of 10 runs slow and 59 362 requests served; 50 connections 7 of 10; 200 connections 10 of 10, 6 361 served. p = 1.1e-5 across the ends.

Fix

ktor-io already declares org.jetbrains.kotlinx:atomicfu as an api dependency and already resolves 0.32.1. kotlinx.atomicfu.locks.SynchronizedObject was rewritten in 0.28.0-beta — changelog: "Implemented thread parking primitives (#498)", "Native mutexes: supported QoS on Apple platforms (#499) and improved implementations on other targets (#512, #517)". The current implementation keeps the owner in an AtomicLong and the waiter count in an AtomicInt, parks losers on a monitor, and allocates nothing. Ktor's file is a copy of the implementation that rewrite replaced.

Deleting the copy is enough. Twelve runs per arm, four builds from the same tree differing in one dependency:

Build	200 conn: slow	p99	Requests	50 conn: slow	p99
3.5.2 as released	12/12	1 500 ms	7 082	7/12	310 ms
pool made lock-free	0/12	11.3 ms	59 924	0/12	7.8 ms
lock delegated to atomicfu	0/12	8.4 ms	59 928	0/12	6.5 ms
both changes	0/12	8.8 ms	60 053	0/12	6.4 ms

Zero of seventy-two patched runs against nineteen of twenty-four stock, p = 1.7e-13. Replacing the lock alone is as good as replacing the pool, and better on p99 and on peak memory.

Reentrancy is preserved. The class being replaced is reentrant (LockState carries a nesting count) and ConcurrentMap takes it at seventeen sites, so re-entry is not hypothetical. atomicfu's replacement is reentrant by the same contract — it is what their own ReentrantLock is built on, and its lock() increments a reEnterCount when the owner is already the current thread. Backed by a run: on the patched tree :ktor-io:macosArm64Test and :ktor-utils:macosArm64Test give 205 tests across 29 suites, 0 failures, 0 skipped, including AttributesTest, ConcurrentSetTest, PipelineTest and the whole ByteChannel set. Note there is no dedicated ConcurrentMap test in the repository, so reentrancy rests on those suites plus the contract; happy to add one in the PR if wanted.

One caveat on the shape of the change, which will save a day. public actual typealias SynchronizedObject = kotlinx.atomicfu.locks.SynchronizedObject compiles and links and then fails at runtime — IrLinkageError: uses unlinked class symbol 'io.ktor.utils.io.locks/SynchronizedObject' — because ktor-utils and ktor-network reference the class by symbol and partial linkage reports the break only when it is reached. Keeping the class and delegating its three methods works and preserves the ABI. That is what the pull request does.

A pull request against release/3.x follows this issue.

Reproducer

A five-rung probe, the harness and every result file are available and can be attached or linked on request; the shape is one route returning one JSON object, embeddedServer(CIO), driven by k6 from a second host at a fixed rate with the connection count as the variable.

OAuth: clients expect to get authenticated once per "session" for all protected routes

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

For all authentication mechanisms, users assume that once a client passes authentication by requesting any of the protected routes (under authenticate block), the server (or a client) saves this knowledge in a "session" and doesn't require it again. This works as expected with basic authentication since a browser saves user/password information and sends it each time it's necessary. But it doesn't work with OAuth because the fact about successful authentication isn't saved anywhere.

Use cases:
https://stackoverflow.com/questions/66779024/oauth2-authorised-routes-not-working-in-ktor
https://stackoverflow.com/questions/66601534/multiple-urlproviders-on-the-same-oauth-setting-in-ktor-with-keycloak

An example solution with sessions:

import io.ktor.application.*
import io.ktor.auth.*
import io.ktor.client.*
import io.ktor.client.engine.apache.*
import io.ktor.client.request.*
import io.ktor.response.*
import io.ktor.routing.*
import io.ktor.server.cio.*
import io.ktor.server.engine.*
import io.ktor.sessions.*
import java.util.*
import java.util.concurrent.ConcurrentHashMap

val githubProvider = OAuthServerSettings.OAuth2ServerSettings(
    name = "github",
    authorizeUrl = "https://github.com/login/oauth/authorize",
    accessTokenUrl = "https://github.com/login/oauth/access_token",
    clientId = "...",
    clientSecret = "...",
    defaultScopes = listOf("repo", "user")
)

data class LoginSession(val userId: String)

typealias UserId = String
typealias AccessToken = String

val tokens = ConcurrentHashMap<UserId, AccessToken>()

fun main() {
    embeddedServer(CIO, port = 8888) {
        install(Authentication) {
            oauth("gitHubOAuth") {
                client = HttpClient(Apache)
                providerLookup = { githubProvider }
                urlProvider = { "http://localhost:8888/callback" }
            }
        }

        install(Sessions) {
            cookie<LoginSession>("LOGIN_SESSION")
        }

        routing {
            authenticate("gitHubOAuth") {
                get("login") {}

                route("callback") {
                    param("error") {
                        handle {
                            call.respondText { call.parameters["error"].orEmpty() }
                        }
                    }
                    handle {
                        val principal = call.authentication.principal<OAuthAccessTokenResponse.OAuth2>()

                        if (principal != null) {
                            val userId = UUID.randomUUID().toString()
                            call.sessions.set(LoginSession(userId))
                            tokens[userId] = principal.accessToken
                        }
                    }
                }
            }

            get("repos") {
                val repos = call.withAuth { session ->
                    HttpClient(Apache).get<String>("https://api.github.com/user/repos") {
                        val token = tokens[session.userId]
                        header("Authorization", "token $token")
                    }
                }

                call.respondText { repos }
            }
        }
    }.start(wait = true)
}

suspend fun <T: Any> ApplicationCall.withAuth(block: suspend (session: LoginSession) -> T): T {
    val session = sessions.get<LoginSession>()

    if (session != null) {
        return block(session)
    }

    respondRedirect("/login")
    throw Exception("Not authenticated")
}

Auth JWK Support (auto-discover)

Other

HttpClient eagerly initializes SLF4J during Android startup

DI: Concurrent module loading can cause a deadlock

ktor-io reader/writer ignores autoFlush

testApplication: call coroutine context isn't preserved when responding with ChannelWriterContent

Typo in KDoc for routing function: "for the this Application".

Digest Auth client: `nc` and `qop` are not handled according to RFC 7616

Documentation for OpenID Connect (OAuth2) auto-discover & configuration

Netty: inverted skippedRead CAS leaves runningLimit read-resumption broken; runningLimit = 1 deadlocks keep-alive connections

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

Symptom

With runningLimit = 1, a keep-alive connection answers exactly one request and then never reads from the socket again. The client waits forever; no error, no close.

	Expected	Observed
`runningLimit = 1`, request #1	200 OK	200 OK
`runningLimit = 1`, request #2 on same connection	200 OK	read timeout, no bytes, connection still open
`runningLimit = 2, 8, 32`, sequential requests	200 OK	200 OK
`runningLimit = 2, 8, 32`, saturate limit then reuse	200 OK	200 OK

Mechanism

ktor-server/ktor-server-netty/jvm/src/io/ktor/server/netty/NettyHttpHandlerState.kt:23

if (skippedRead.compareAndSet(expect = false, update = true) && activeRequests.value < runningLimit) {
    context.read()
}

NettyHttp1Handler.kt:334-341 (callReadIfNeeded) sets skippedRead = true precisely when a read was skipped because the limit was reached. So the CAS succeeds only when nothing was skipped — context.read() is re-armed in the one case it is not needed, and never in the case it is.

The channel runs with isAutoRead = false (NettyHttp1Handler.kt:83), so a read must be re-armed explicitly. At runningLimit = 1 every request drives activeRequests to the limit, so no callReadIfNeeded in the read cycle ever sees spare capacity, Netty's readPending is never re-set, and the connection is never read from again.

Limits above 1 recover incidentally: an earlier context.read() in the same read cycle (issued while activeRequests was still below the limit) leaves readPending set for the next cycle.

The pendingMessages queue makes runningLimit a hard cap, which is the other half of item 2, but it was built around this condition without correcting it. It masks the problem whenever there are queued messages to replay, because drainPending → dispatchMessage → callReadIfNeeded re-arms the read as a side effect.

Impact

runningLimit is a public configuration (NettyApplicationEngine.Configuration.runningLimit) with no validation, so 1 is a reachable value and a natural way to serialise requests per connection. It silently deadlocks every keep-alive connection.

Netty performance issues

Netty: engine double-responds after its built-in 400, crashing the call-handler coroutine with "Headers can no longer be set because response was already completed"

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

Summary

On ktor 3.5.2 the Netty engine
crashes the call-handler coroutine with:

java.lang.UnsupportedOperationException: Headers can no longer be set because response was already completed
    at io.ktor.server.netty.http1.NettyHttp1ApplicationResponse$headers$1.engineAppendHeader(NettyHttp1ApplicationResponse.kt:45)
    at io.ktor.server.response.ResponseHeaders.append(ResponseHeaders.kt:71)
    at io.ktor.server.engine.BaseApplicationResponse.commitHeaders(BaseApplicationResponse.kt:90)
    at io.ktor.server.engine.BaseApplicationResponse.respondOutgoingContent$suspendImpl(BaseApplicationResponse.kt:135)
    at io.ktor.server.netty.NettyApplicationResponse.respondOutgoingContent$suspendImpl(NettyApplicationResponse.kt:41)
    ...
    at io.ktor.server.engine.DefaultEnginePipelineKt.tryRespondError(DefaultEnginePipeline.kt)
    at io.ktor.server.engine.DefaultEnginePipelineKt.handleFailure(DefaultEnginePipeline.kt:72)
    at io.ktor.server.netty.http1.NettyHttp1Handler$handleRequest$1$1.invokeSuspend(NettyHttp1Handler.kt:191)

logged as Unhandled exception caught for CoroutineName(call-handler) on the application logger.
On a public endpoint this is high-volume noise. The events carry empty url/transaction
because the request never reaches routing — StatusPages cannot intercept this path.

This is the same exception as KTOR-8410, which was closed as "Can't Reproduce". Below is the exact
mechanism; the trigger race is real traffic (malformed request + connection teardown), which is why
it is hard to hit in a local repro but constant in production.

Mechanism (ktor 3.5.1 sources)

A client sends a request Netty's HTTP decoder rejects (or one with an invalid
Transfer-Encoding list) → NettyHttp1Handler.handleRequest:
!call.request.isValid() → call.respondError400BadRequest().
respondError400BadRequest (NettyApplicationCallHandler.kt) writes the 400 via
response.sendResponse(chunked = false, content) — this sets the engine-level
responseMessageSent = true and completes responseReady with success, but never touches
BaseApplicationResponse state: isCommitted and isSent stay false (nothing called
commitHeaders, and isSent is only set at the end of respondOutgoingContent).
The connection dies while the 400 is being finished (bot disconnects; exceptionCaught →
handlerJob.cancel()), so finish() / responseWriteJob.join() throws a
CancellationException out of respondError400BadRequest.
The catch (error: Throwable) in NettyHttp1Handler.handleRequest (line 190) calls
handleFailure(call, error) → tryRespondError. Its guard is
if (call.response.isCommitted || call.response.isSent) return — both are false (step 2),
so it calls call.respond(...) → commitHeaders → engineAppendHeader.
engineAppendHeader sees responseMessageSent == true. Its benign branch requires
responseReady.isCancelled, but the promise completed with success (step 2), so it throws
UnsupportedOperationException("Headers can no longer be set because response was already completed"). The exception escapes handleFailure, fails the coroutine and reaches the
uncaught-exception handler (it is not a CancellationException/IOException, so it is logged
at error level).

In short: the engine's own channel-level 400 desynchronizes the engine state
(responseMessageSent) from the call state (isCommitted/isSent), and the engine's own failure
fallback then trusts the call state and double-responds.

KTOR-8410's stack (Sessions cookie append inside a StatusPages handler) is another entry point
into the same desynchronized state.

Suggested fix (one line)

Mark the call as answered when the engine answers at the channel level, in
NettyApplicationCallHandler.respondError400BadRequest:

response.sendResponse(chunked = false, content)
response.isSent = true   // channel-level response == the call is answered
finish()

tryRespondError's existing guard then short-circuits and the crash disappears. Setting isSent
inside sendResponse itself would be wrong — that function is also on the streaming path
(responseChannel()), where isSent must keep meaning "body fully written".

Deterministic regression test

No connection race needed — both functions are reachable from ktor-server-netty tests:

// call = a NettyHttp1ApplicationCall whose request failed decoding
call.respondError400BadRequest()
handleFailure(call, RuntimeException("simulated failure after the built-in 400"))
// before the fix: UnsupportedOperationException("Headers can no longer be set...")
// after the fix: no throw

Environment

ktor 3.5.2 (Netty engine, enableHttp2 = true, enableH2c = true), JDK 25, Linux

ServletApplicationEngine: Application events aren't triggered

Jackson/Gson converters waste time on unnecessary Dispatchers.IO dispatch

Micro-benchmark	Result
`withContext(Dispatchers.IO) {}` (empty)	8,802 ± 311 ns
Jackson raw parse, 10-element list (~400 B JSON)	2,282 ± 77 ns
`toInputStream` drain of buffered 64 KB channel	2,152 ns, 72 B/op (no runBlocking on the buffered path)
Full `JacksonConverter.deserialize` of the same payload	14,608 ± 380 ns

Apache5: Upgrading Apache HttpClient5 to version 5.6 breaks the Ktor client with `Content-Length mismatch` error for any gzipped content

Client curated multi-platform facade module

OkHttp: Reduce coroutine dispatching and allocations while reading response bodies

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

Problem

The OkHttp client copies response bodies through a producer coroutine and an intermediate ByteChannel:

ResponseBody.source()
  -> BufferedSource.toChannel(callContext, requestData)
  -> GlobalScope.writer(callContext)
  -> ByteChannel
  -> response consumer

The response-copy loop reads approximately one 4–8 KiB chunk at a time. For a 2 MiB response this produces about 513 iterations.

The loop calls:

channel.write { buffer ->
    lastRead = source.read(buffer)
}
channel.flush()

The ByteWriteChannel.write(ByteBuffer) already calls flush(). The second flush is therefore redundant and creates another suspend continuation invocation on every iteration. Allocation measurements show two ByteChannel$flush$1 continuation sites, each totaling approximately 24.6 KiB per 2 MiB request.

Even after removing the duplicate flush, write() still invokes suspending flush() for every source read. Most calls do not suspend because the channel has free capacity, but they retain continuation overhead and increase opportunities for producer/consumer scheduling changes.

Coroutine migration also affects Okio's JVM segment pool because pool buckets are selected from the current thread. A migration can move later reads to another bucket, while bucket contention can produce an okio.Segment and paired 8 KiB ByteArray allocation despite pooled segments being available elsewhere.

Allocation evidence

From ktor-benchmarks against the baseline:

client/streamingResponse[OkHttp]: +3,869 bytes total

Allocations under OkHttpEngine.toChannel included paired [B and okio.Segment allocations. The deterministic duplicate-flush cost was approximately 24.6 KiB per request; the segment-pool variance is scheduler-sensitive.

Testing

Add an OkHttp engine test that keeps the source open after emitting its first byte and verifies that the consumer receives that byte before EOF. This protects immediate publication without requiring a suspending flush per source read.

Support nested jars in static resources

Cancel blocking bridges when coroutine is cancelled

Support HTTP/3 for Netty

Documentation for Support at least zstd and deflate formats of precompressed files

Support at least zstd and deflate formats of precompressed files

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

Currently, when serving pre-compressed files you can only serve them in 2 formats:

brotli
gzip

there is no option to serve them in other formats such as zstd or deflate (for older browsers).

this is configured by doing something similar to the following:

staticFiles("/", File("./public/")) {
    preCompressed(
        CompressedFileType.BROTLI,
        CompressedFileType.GZIP,
        CompressedFileType.DEFLATE,
        CompressedFileType.ZSTD,
    )

    // ...
}

According to MDN, here is a list of all valid directives for Accept-Encoding/Content-Encoding:

gzip
compress (not supported by most browsers due to patent stuff, see MDN)
deflate
br
zstd
dcb (brotli using a custom dictionary, see MDN) (experimental, only supported by chrome ≥130)
dcz (zstd using a custom dictionary, see MDN) (experimental, only supported by chrome ≥130)

I think support for, at the very least, zstd and deflate should be added.

to add support for these compression formats (as well as a few other changes), in my projects what I have been doing is copying PreCompressed.kt and replacing the CompressedFileType enum with the following:

data class CompressedFileType(val extension: String, val encoding: String = extension) {
    companion object {
        val BROTLI = CompressedFileType("br")
        val GZIP = CompressedFileType("gz", "gzip")
        val DEFLATE = CompressedFileType("deflate")
        val ZSTD = CompressedFileType("zst", "zstd")
    }
}

imo it would make a lot more sense if CompressedFileType was a data class rather than an enum as it would allow users to specify custom compressed file types if they so desired (for example when the user controls both the client and the server and wishes to use their own custom pre-compressed file type, or if in the future another algorithm like bzip2 or lzma are added to the list of supported compression algorithms). However, this would be a breaking change and would not be able to be integrated into the existing api without doing something like deprecating the existing api and coming up with a new name for the new api.

Documentation for Support nullable types in ApplicationCall.receive

Support nullable types in ApplicationCall.receive

Documentation for DefaultConversionService: Support Uuid type introduced in Kotlin 2.0

Documentation for Support HTTP/3 for Netty

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

In 3.6.0, we're providing support for QUIC and HTTP/3 in the Netty server engine.

You can enable this in the engine config using enableHttp3(). This function also accepts a scoped lambda for HTTP/3-specific configuration:

embeddedServer(Netty, environment, {
    // SSL connector is required
    sslConnector(
        keyStore = keyStore,
        keyAlias = "server",
        keyStorePassword = { "changeit".toCharArray() },
        privateKeyPassword = { "changeit".toCharArray() }
    ) {
        port = 8443
        host = "0.0.0.0"
    }

    enableHttp3 {
        quicTokenHandler = HmacQuicTokenHandler() // optional
        quicMaxIdleTimeout = 30.seconds
        quicInitialMaxData = 10_000_000
        quicInitialMaxStreamDataBidirectionalLocal = 1_000_000
        quicInitialMaxStreamDataBidirectionalRemote = 1_000_000
        quicInitialMaxStreamsBidirectional = 100
        udpSocketCount = 1
        udpReceiveBufferSize = 0
        udpSendBufferSize = 0
        configureQuicServerCodec = { /* optional low-level Netty tuning */ }
    }
}) { /* application */ }.start(wait = true)

`enableHttp3 {}` options

Option	Type	Default	Purpose	Constraints / Notes
`quicTokenHandler`	`QuicTokenHandler?`	`null`	Enables QUIC Retry/address validation tokens	`null` = no Retry; setting adds handshake RTT but improves anti-spoofing protection
`quicMaxIdleTimeout`	`Duration`	`30.seconds`	Max idle time before closing QUIC connection	Must be `> 0`
`quicInitialMaxData`	`Long`	`10_000_000`	Connection-level flow-control window (bytes)	Must be `> 0`
`quicInitialMaxStreamDataBidirectionalLocal`	`Long`	`1_000_000`	Per-stream flow-control (locally initiated bidi streams)	Must be `> 0`
`quicInitialMaxStreamDataBidirectionalRemote`	`Long`	`1_000_000`	Per-stream flow-control (remotely initiated bidi streams)	Must be `> 0`
`quicInitialMaxStreamsBidirectional`	`Long`	`100`	Max concurrent bidirectional streams peer may open	Must be `> 0`
`udpSocketCount`	`Int?`	`null`	Number of UDP sockets for HTTP/3 listener	Must be `null` or `> 0`; values `> 1` require `SO_REUSEPORT` support
`udpReceiveBufferSize`	`Int`	`0`	UDP `SO_RCVBUF` size	`0` = OS default; must be `>= 0`
`udpSendBufferSize`	`Int`	`0`	UDP `SO_SNDBUF` size	`0` = OS default; must be `>= 0`
`configureQuicServerCodec`	`QuicServerCodecBuilder.() -> Unit`	`{}`	Advanced low-level Netty QUIC customization	Use with care, especially when using multiple UDP sockets

Documentation for respondHtmlPartial

Documentation for OpenAPI: No way to set tag description

Documentation for WebRTC client on JVM

Documentation for Commonize HttpCache FileCacheStorage

Documentation for Client curated multi-platform facade module

Documentation for ContentNegotiation: Add a way to prevent changing Accept and Content-Type headers

Documentation for Add resource attribute for client resources plugin

Documentation for Async CIO DNS resolver with timeout

Documentation for Override fetch in JS engine

Documentation for Make ApplicationCallPipeline.ApplicationPhase.Validators public in 3.6.0

Documentation for Allow H2C and HTTP/2 on same server

Documentation for Ktor Cookie.parseClientCookiesHeader returns Map, which breaks Cookie header contract

Ktor Cookie.parseClientCookiesHeader returns Map, which breaks Cookie header contract

OIDC Server Plugin

Allow H2C and HTTP/2 on same server

Make ApplicationCallPipeline.ApplicationPhase.Validators public in 3.6.0

Override fetch in JS engine

Typesafe Authentication DSL

Auth: Non-optional principal is of nullable type

Async CIO DNS resolver with timeout

Add resource attribute for client resources plugin

ContentNegotiation: Add a way to prevent changing Accept and Content-Type headers

OpenAPI: No way to set tag description

Use TagConsumer in respondHtmlFragment lambda receiver

Authorization header removed from refresh token request

Bad percentage encoding in URL query causes uncaught exception and 500 status

Android: can hang when cancelling a streaming response during a blocking read

OpenAPI: "No mapping for symbol: VALUE_PARAMETER" exception when respondText receives a conditional ContentType within ApplicationCall extension function

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

Component: OpenAPI

Affects: Ktor 3.4.1, Kotlin 2.3.10

Possibly Related: KTOR-9305

Description:

The OpenAPI compiler plugin (ktor-compiler-plugin:3.4.1) with codeInferenceEnabled = true (the default) causes an internal compiler error when a Route extension function:

1. Captures many parameters (9+ in my case)

2. Registers nested route handlers that use local variables

The error occurs in the JVM codegen phase, not in the plugin's analysis phase — the plugin's IR transformation creates symbol references that the IrFrameMap doesn't have mappings for.

Error:

e: java.lang.RuntimeException: Exception while generating code for:

FUN name:myHandler visibility:public modality:FINAL returnType:kotlin.Unit

...

Caused by: java.lang.IllegalStateException: No mapping for symbol: VALUE_PARAMETER kind:ExtensionReceiver name:$this$get index:0 type:io.ktor.server.routing.RoutingContext

at org.jetbrains.kotlin.backend.jvm.codegen.IrFrameMap.typeOf(irCodegenUtils.kt:59)

In a larger codebase the same root cause manifests as:

No mapping for symbol: VAR name:contentType type:io.ktor.http.ContentType [val]

Minimal reproducer: https://github.com/elee/kotlin-playground './gradlew compileKotlin` to reproduce

build.gradle.kts:

plugins {

kotlin("jvm") version "2.3.10"

id("io.ktor.plugin") version "3.4.1"

}

ktor { openApi { enabled = true } }

application { mainClass.set("repro.ApplicationKt") }

repositories { mavenCentral() }

dependencies {

kotlinCompilerPluginClasspath("io.ktor:ktor-compiler-plugin:3.4.1")

implementation("io.ktor:ktor-server-core-jvm:3.4.1")

implementation("io.ktor:ktor-server-netty-jvm:3.4.1")

implementation("io.ktor:ktor-server-openapi:3.4.1")

implementation("io.ktor:ktor-server-resources:3.4.1")

}

src/main/kotlin/repro/Routing.kt:

package repro

import io.ktor.http.*

import io.ktor.server.application.*

import io.ktor.server.request.*

import io.ktor.server.response.*

import io.ktor.server.routing.*

interface SomeService { fun getData(): String }

fun Route.myHandler(a: SomeService, b: SomeService, c: SomeService,

d: SomeService, e: SomeService, f: SomeService,

g: SomeService, h: SomeService, i: SomeService) {

route("/items") {

get { call.respond(a.getData()) }

route("/{id}") {

get { call.respond(b.getData()) }

get("/log/{logName...}") {

val parts = call.parameters.getAll("logName")!!

if (parts.lastOrNull() == "pretty") {

val html = call.request.accept()?.contains("text/html") ?: false

call.respondText(c.getData(),

if (html) ContentType.Text.Html else ContentType.Text.Plain)

return@get

}

call.respondText("raw")

}

post("/cancel") { call.respond(d.getData()) }

post("/stop") { call.respond(e.getData()) }

get("/findings") { call.respond(f.getData()) }

post("/findings") { call.respond(g.getData() + call.receiveText()) }

get("/status") { call.respond(h.getData()) }

delete { call.respond(i.getData()) }

}

fun Application.configureRouting() {

routing {

route("/api") {

val svc = object : SomeService { override fun getData() = "x" }

myHandler(svc, svc, svc, svc, svc, svc, svc, svc, svc)

}

src/main/kotlin/repro/Application.kt:

package repro

import io.ktor.server.application.*

import io.ktor.server.netty.*

fun main(args: Array<String>): Unit = EngineMain.main(args)

fun Application.module() { configureRouting() }

Steps to reproduce:

./gradlew compileKotlin

Expected: Compilation succeeds.

Actual: IllegalStateException: No mapping for symbol in JVM codegen.

Workaround: Set codeInferenceEnabled = false in ktor { openApi {} }, but this disables all OpenAPI inference, producing an empty spec. We could also describe every single parameter and return type but this is not ideal.

Notes:

- The crash does NOT occur with fewer captured parameters (e.g. 3)

- The crash does NOT occur without the nested route structure

- The crash occurs in org.jetbrains.kotlin.backend.jvm.codegen.IrFrameMap.typeOf, suggesting the compiler plugin's IR transformations introduce variable references that aren't registered

in the JVM codegen's frame map

- This appears to be a variant of KTOR-9305 which was fixed for FOR_LOOP_VARIABLE but the underlying issue remains for VALUE_PARAMETER and regular VAR symbols in the same scenario

OpenAPI: "No mapping for symbol: VAR name" exception when code inference is on

OpenAPI: "IllegalStateException: No mapping for symbol" when code inference and passing received body to HttpStatusCode()

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

Subsystem: Server

Type: Bug

Affected versions: 3.4.0, 3.4.1, 3.4.2

Description:

KTOR-9305 fixed the FOR_LOOP_VARIABLE variant of this crash in 3.4.1, but the same root cause (No mapping for symbol in IrFrameMap.typeOf) still triggers for local variables in route handler lambdas.

The code inference compiler plugin incorrectly captures a local variable from a post-lambda body into the enclosing route lambda's invokedynamic closure. The crash requires all three of these elements together – removing any one avoids it:

1. Property delegates (e.g. Kodein by di.instance()) in the outer Route function scope

2. authenticate { route { post { ... }.describe { } } } lambda nesting

3. ?: return@post call.someExtensionFn(...) - an elvis operator with a labeled return that calls a suspend extension function on ApplicationCall with default parameters

Important: The Gradle daemon masks this crash by caching compiled outputs. You must build with:

./gradlew clean compileKotlin --no-daemon --no-build-cache

Reproduction:

// build.gradle.kts
plugins {
  id("io.ktor.plugin")
  kotlin("plugin.serialization")
}
ktor {
  openApi {
    enabled = true
    codeInferenceEnabled = true
  }
}
// + ktor-server-auth dependency for authenticate {}
// + kodein-di dependency for DI property delegates

@file:OptIn(io.ktor.utils.io.ExperimentalKtorApi::class) 
package com.example

import io.ktor.http.HttpStatusCode
import io.ktor.server.application.ApplicationCall
import io.ktor.server.auth.authenticate
import io.ktor.server.request.receive
import io.ktor.server.response.respond
import io.ktor.server.routing.Route
import io.ktor.server.routing.openapi.describe
import io.ktor.server.routing.post
import io.ktor.server.routing.route
import kotlinx.serialization.Serializable
import org.kodein.di.DI
import org.kodein.di.instance

interface MyApiError {
    val status: HttpStatusCode
    val message: String
}

data class NotFoundError(val id: String) : MyApiError {
    override val status = HttpStatusCode.NotFound
    override val message = "Not found: $id"
}

interface MyService {
    fun lookup(id: String): String?
}

@Serializable
data class MyRequest(val model: String)

// Suspend extension function with a default parameter — this is the
// function whose call site inside `?: return@post` triggers the crash.
suspend fun ApplicationCall.respondError(
    error: MyApiError,
    message: String? = null,
) {
    respond(status = error.status, message = message ?: error.message)
}

fun Route.example(di: DI) {
    val svcA: MyService by di.instance()
    val svcB: String by di.instance()
    val svcC: String by di.instance(tag = "c")
    val svcD: Long by di.instance()
    val svcE: Double by di.instance()
    val svcF: Boolean by di.instance()
    val svcG: Int by di.instance()

    authenticate("test") {
        route("example") {
            post("cost") {
                val request = call.receive<MyRequest>()
                val model = svcA.lookup(request.model)
                    ?: return@post call.respondError(NotFoundError(request.model))
                call.respond(HttpStatusCode.OK, model)
            }.describe {
                summary = "Cost"
            }
        }
    }
}

Expected: Compilation succeeds.

Actual: Internal compiler error:

java.lang.IllegalStateException: No mapping for symbol:
  AR name:request type:com.example.MyRequest [val]
  at ...IrFrameMap.typeOf(irCodegenUtils.kt:59)

Environment: Kotlin 2.3.20, Ktor 3.4.2, Gradle 9.3.1

Workaround: codeInferenceEnabled = false

Multipart is not supported on non-JVM server targets

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

call.receiveMultipart() fails on non-JVM server targets (Native, JS/Wasm) with:

io.ktor.server.plugins.CannotTransformContentToTypeException:
Cannot transform this request's content to io.ktor.http.content.MultiPartData

Reported on GitHub: https://github.com/ktorio/ktor/issues/5694 (linuxX64, reproduced on 3.0.3 / 3.4.0 / 3.5.0)

Root cause

The default receive transformation delegates multipart handling to an expect function that has no working non-JVM implementation:

ktor-server-core/common/src/io/ktor/server/engine/DefaultTransform.kt has no MultiPartData branch; it falls through to defaultPlatformTransformations.
The JVM actual (DefaultTransformJvm.kt) handles MultiPartData::class -> multiPartData(channel).
The nonJvm actual (DefaultTransform.nonJvm.kt) returns null, so the body stays a ByteReadChannel and PipelineCall throws CannotTransformContentToTypeException.

This is a server-core wiring gap, not an engine issue: the request Content-Type is parsed correctly and call.receiveChannel() works.

Second symptom (same root cause)

call.receiveParameters() with a multipart/form-data body hits the common Parameters::class branch, which calls multiPartData(channel) directly. The nonJvm actual is error("Multipart is not supported on non JVM platforms"), so this fails with IllegalStateException instead of the exception above.

Why the stub is stale

0de7948fb (KTOR-746, Native CIO server, 2021) — the CIO multipart parser lived in ktor-http-cio/jvm/ only, so a non-JVM stub was unavoidable.
1115fae6f (JS/Wasm server commonization, 2024-08) — parser still JVM-only, the stub was copied to jsAndWasmShared.
4933074bb (KTOR-6632, "Support receiving multipart data with Ktor client", shipped in 3.1.0) — CIOMultipartDataBase and parseMultipart were moved to ktor-http-cio/common/, with only discardBlocking() left as expect/actual. From this point the parser works on all targets, and the client uses it from commonMain. The server side was not re-wired.
d0d6a7e83 (nonJvm source-set cleanup, 2025) — the stub was relocated to nonJvm without re-checking whether it was still needed.

The workaround in the GitHub issue (constructing CIOMultipartDataBase by hand on Native) confirms the parser itself works off-JVM.

Suggested fix

Move the JVM multiPartData implementation into commonMain and add a MultiPartData::class branch to the common when. No new dependency is needed (ktor-server-core already has api(projects.ktorHttpCio) in commonMain) and no public API changes (everything involved is internal).

OpenAPI: generated schema for recursive types uses invalid schemaRef with ReflectionJsonSchemaInference

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

Description

When using ReflectionJsonSchemaInference to generate OpenAPI specification for recursive types, the inner schema reference for the property uses a fully qualified class name, while the actual schema name is shortened to the simple type name.

Steps to reproduce

import com.fasterxml.jackson.databind.ObjectMapper
import io.ktor.client.request.get
import io.ktor.client.statement.bodyAsText
import io.ktor.http.ContentType
import io.ktor.openapi.OpenApiInfo
import io.ktor.openapi.reflect.ReflectionJsonSchemaInference
import io.ktor.serialization.jackson.jackson
import io.ktor.server.plugins.contentnegotiation.ContentNegotiation
import io.ktor.server.plugins.swagger.swaggerUI
import io.ktor.server.response.respond
import io.ktor.server.routing.get
import io.ktor.server.routing.openapi.OpenApiDocSource
import io.ktor.server.testing.testApplication
import org.junit.jupiter.api.Assertions.assertEquals
import org.junit.jupiter.api.Test

class RecursiveTypeSchemaReferenceTest {

    data class Value(val name: String, val children: List<Value>)

    @Test
    fun `refs in openapi schema are correct for recursive types`() = testApplication {
        install(ContentNegotiation) {
            jackson()
        }

        routing {
            swaggerUI("/swagger-internal") {
                info = OpenApiInfo("Shapes API", "1.0")
                source = OpenApiDocSource.Routing(
                    contentType = ContentType.Application.Json,
                    schemaInference = ReflectionJsonSchemaInference.Default,
                )
                remotePath = "documentation.json"
            }

            get("/myValue") {
                call.respond(Value("test", emptyList()))
            }
        }

        val specResponse = client.get("/swagger-internal/documentation.json").bodyAsText()

        val spec = ObjectMapper().readTree(specResponse)
        val childrenItemsRef = spec
            .path("components")
            .path("schemas")
            .path("Value")
            .path("properties")
            .path("children")
            .path("items")
            .path("\$ref")
            .asText()

        assertEquals("#/components/schemas/Value", childrenItemsRef)
    }
}

Expected behavior

An OpenAPI specification with the following components:

"components": {
  "schemas": {
    "Value": {
      "type": "object",
      "title": "Value",
      "required": [
        "children",
        "name"
      ],
      "properties": {
        "children": {
          "type": "array",
          "items": {
            "$ref": "#/components/schemas/Value"
          }
        },
        "name": {
          "type": "string"
        }
      }
    }
  }
}

Actual behavior

"components": {
  "schemas": {
    "Value": {
      "type": "object",
      "title": "Value",
      "required": [
        "children",
        "name"
      ],
      "properties": {
        "children": {
          "type": "array",
          "items": {
            "$ref": "#/components/schemas/no.nav.pensjon.brev.skribenten.openapi.RecursiveTypeSchemaReferenceTest.Value"
          }
        },
        "name": {
          "type": "string"
        }
      }
    }
  }
}

OpenAPI: Support the "const" validation keyword

DefaultConversionService: Support Uuid type introduced in Kotlin 2.0

Incorrect warning about streaming compression buffering

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

When using compression with a response that uses OutgoingContent.WriteChannelContent, the following message is logged:

2026-06-25 13:25:39,125 [eventLoopGroupProxy-4-]            WARN  io.ktor.server.plugins.compression.Compression   - Compressing a WriteChannelContent response for [api route here]. Compression will buffer the entire body before sending, which defeats the purpose of streaming. Consider suppressing compression for this route with call.suppressCompression().

there are a couple of issues with this

this log message is present for every request that is made, rather than just a single time, which can be quite expensive.
this warning is just incorrect.

on top of the code that logs this warning, the following comment is present:

// Most compression algorithms (e.g. gzip, deflate, brotli) cannot compress streaming responses
// incrementally without buffering the entire body, which defeats the purpose of streaming.

this is just factually incorrect.
although all of the compression algorithms do need to buffer content in order to compress it, it is still streamed.
i.e. it does not need to buffer the entire response in order to compress it. there is not a single compression algorithm that does this.

the following code snippet is from Deflater.kt. this is the code path that anything using WriteChannelContent would hit if it were using gzip or deflate compression.

private suspend fun ByteReadChannel.deflateTo(
    destination: ByteWriteChannel,
    gzip: Boolean = true,
    pool: ObjectPool<ByteBuffer> = KtorDefaultPool
) {
    val crc = CRC32()
    val deflater = Deflater(Deflater.DEFAULT_COMPRESSION, true)
    val input = pool.borrow()
    val compressed = pool.borrow()

    try {
        if (gzip) {
            destination.putGzipHeader()
        }

        while (!isClosedForRead) {
            input.clear()
            if (readAvailable(input) <= 0) continue
            input.flip()

            crc.updateKeepPosition(input)
            deflater.setInputBuffer(input)
            destination.deflateWhile(deflater, compressed) { !deflater.needsInput() }
        }

        closedCause?.let { throw it }

        deflater.finish()
        destination.deflateWhile(deflater, compressed) { !deflater.finished() }

        if (gzip) {
            destination.putGzipTrailer(crc, deflater)
        }
    } finally {
        deflater.end()
        pool.recycle(input)
        pool.recycle(compressed)
    }
}

as you can see, it streams the compressed response using a temporary byte buffer from a pool

HttpCache add method for clearing

Netty HTTP/3: the listener can only ever serve ONE QUIC connection — every subsequent handshake times out

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

Affected versions

Unreleased: main (3.6.0-SNAPSHOT), commit fc6595632e7412abb98b941f926d0ea13c7647d1.
HTTP/3 support introduced in PR ktorio/ktor#5527.

Problem

With enableHttp3(), the first QUIC connection to the server works; every QUIC connection
after it — concurrent or after the first one closed — never completes its handshake and
times out. In practice the HTTP/3 listener serves exactly one browser/client per process
lifetime.

Observed with a Netty h3 client against a freshly started server (5s connect timeout):

[probe] conn1 (fresh listener): connected in 821ms
[probe] conn1: GET /i -> ok
[probe] conn2 (while conn1 still open): CONNECT TIMED OUT after 5s
[probe] conn1 closed
[probe] conn3 (after conn1 closed): CONNECT TIMED OUT after 5s

Root cause

NettyHttp3ChannelInitializer.kt:49:

.handler(Http3ServerConnectionHandler(streamInitializer))

A single Http3ServerConnectionHandler instance is passed to
QuicServerCodecBuilder.handler(...), which installs it into the pipeline of every
incoming QuicChannel. But Http3ServerConnectionHandler is explicitly non-sharable: its
superclass Http3ConnectionHandler overrides isSharable() to always return false —
"Always returns false as it keeps state"
— since it owns the connection's control-stream and QPACK state. Netty therefore rejects
adding the same instance to a second pipeline (ChannelPipelineException: ... is not a @Sharable handler, so can't be added or removed multiple times), the second connection's
initialization fails, and its handshake never completes. Netty's own HTTP/3 server example
wraps the connection handler in a ChannelInitializer<QuicChannel> that creates a new
instance per connection.

(Interestingly, the per-STREAM level got this right — NettyHttp3RequestStreamInitializer
creates a new NettyHttp3Handler per stream, its KDoc even noting request stream handlers
are not sharable. The connection level was missed.)

Fix

A PR with this change and a regression test follows.

.handler(object : ChannelInitializer<QuicChannel>() {
    override fun initChannel(ch: QuicChannel) {
        ch.pipeline().addLast(Http3ServerConnectionHandler(streamInitializer))
    }
})

streamInitializer (a ChannelInitializer) is sharable by design and can stay shared.

After the fix, the same probe:

[probe] conn1 (fresh listener): connected in 16ms
[probe] conn1: GET /i -> ok
[probe] conn2 (while conn1 still open): connected in 15ms
[probe] conn2: GET /i -> ok
[probe] conn1 closed
[probe] conn3 (after conn1 closed): connected in 26ms
[probe] conn3: GET /i -> ok

Regression test attached: NettyHttp3MultipleConnectionsTest (drop into
ktor-server/ktor-server-netty/jvm/test/io/ktor/tests/server/netty/) — it opens a second
connection while the first is still open, and another one after the first has closed, and
asserts that both connect and serve requests. Fails on current main, passes with the fix.

Duplicate code in ByteReadChannel

OpenAPI Contextual JSON schema inference support

Misleading log output for Unix Domain Socket servers: "Responding at unix://0.0.0.0:80"

CIO: The engine doesn't encode Unicode symbols like '–' (U+2013) in request URL

Log which ConfigLoader has been used for loading the server configuration

CharsetDecoder.decode() ignores the max argument on JVM

Commonize HttpCache FileCacheStorage

WebRTC client on JVM

Escape `$` in application.yaml file

Unescape quoted-pair at the end of a header parameter value

CIO: HttpRequestLifecycle cancels `Connection: close` call too soon, sending an incomplete response

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

Ktor CIO with HttpRequestLifecycle { cancelCallOnClose = true } cancels an in-flight handler when the request carries a Connection: close header, so the server closes the socket with zero response bytes while the still-connected client is blocked reading the response. Reproduced with Ktor 3.4.1 and 3.5.1, JVM.

Per RFC 9112 §9.6 a server that receives Connection: close MUST send the final response before initiating closure — the close connection option is a persistence signal about what happens after the exchange completes, not licence to abort the in-flight request. A one-shot client that sends Connection: close, keeps the socket open, and reads to EOF must observe a complete HTTP response.

package ktor.repro

import io.ktor.server.application.install
import io.ktor.server.cio.CIO
import io.ktor.server.engine.embeddedServer
import io.ktor.server.http.HttpRequestLifecycle
import io.ktor.server.response.respondText
import io.ktor.server.routing.post
import io.ktor.server.routing.routing
import kotlinx.coroutines.CancellationException
import kotlinx.coroutines.CompletableDeferred
import kotlinx.coroutines.delay
import kotlinx.coroutines.runBlocking
import kotlinx.coroutines.withTimeoutOrNull
import java.io.OutputStream
import java.net.Socket
import kotlin.test.Test
import kotlin.test.assertEquals
import kotlin.test.assertTrue
import kotlin.time.Duration.Companion.seconds

/**
 * Mechanism (CIO):
 * - The per-connection parse loop in `ServerPipeline.kt` `break`s on a `Connection: close` request as soon as the request body is
 *   read, and its `finally` block then invokes `handlerScope.onClose` — before the response is written, while the handler coroutine
 *   may still be suspended.
 * - `CIOApplicationEngine.setCloseHandler` wires `onClose` to the call attribute installed by `HttpRequestLifecycle`'s `CallSetup`
 *   hook, which with `cancelCallOnClose = true` does `call.coroutineContext.cancel(...)`.
 * - The cancelled handler closes its response `ByteChannel` with the cancellation cause, the writer loop copies 0 bytes, and the
 *   connection output closes — the client observes a clean EOF with an empty (or truncated) HTTP response.
 *
 * The callback registration itself races the parse loop: `setCloseHandler` and the `CallSetup` hook run on the user dispatcher,
 * while the parse loop reaches its `finally` on the engine side almost immediately for a request that arrives in one piece — then
 * `onClose` is still unset and the call completes normally. That makes the bug appear only under load in real deployments. The
 * first test pins the race deterministically by withholding the request body until the handler has started: the parse loop is
 * parked in `parseHttpBody` until after registration, so on body arrival it breaks and cancels the suspended handler every time.
 *
 * The second test shows the plugin's intended behavior works: a real client disconnect cancels the suspended handler. For
 * contrast, the Netty engine passes both tests on 3.4.1 and 3.5.1 — it invokes the close callback only from `channelInactive`
 * (a real disconnect), never for a `Connection: close` request.
 */
class ConnectionCloseCancellationTest {

  @Test
  fun `Connection close request receives a complete response from a suspending handler`() = runBlocking<Unit> {
    val handlerStarted = CompletableDeferred<Unit>()
    val handlerOutcome = CompletableDeferred<String>()
    val server = embeddedServer(CIO, port = 0, host = "127.0.0.1") {
      install(HttpRequestLifecycle) {
        cancelCallOnClose = true
      }
      routing {
        post("/slow") {
          handlerStarted.complete(Unit)
          try {
            delay(3.seconds) // a handler that suspends before responding, e.g. awaiting some external state
            call.respondText("pong")
            handlerOutcome.complete("completed")
          } catch (cause: CancellationException) {
            handlerOutcome.complete("cancelled")
            throw cause
          }
        }
      }
    }
    server.startSuspend(wait = false)
    try {
      val port = server.engine.resolvedConnectors().single().port
      val response = Socket("127.0.0.1", port).use { socket ->
        socket.soTimeout = 30_000
        socket.getOutputStream().sendRequestWithheldBody(connectionClose = true) {
          handlerStarted.await()
        }
        // one-shot HTTP/1.1 client: read until EOF; the socket stays fully open meanwhile (no half-close)
        socket.getInputStream().readBytes().decodeToString()
      }
      val outcome = withTimeoutOrNull(5.seconds) { handlerOutcome.await() } ?: "still suspended"
      assertTrue(
        response.contains("\r\n\r\n"),
        "Malformed HTTP response: missing header terminator; " +
          "server closed after ${response.length} bytes (handler outcome: $outcome): \"$response\"",
      )
      assertTrue(response.startsWith("HTTP/1.1 200"), "Expected a 200 response (handler outcome: $outcome), got: \"$response\"")
      assertTrue(response.endsWith("pong"), "Expected the full body (handler outcome: $outcome), got: \"$response\"")
      assertEquals("completed", outcome, "Full response received, so the handler must have run to completion")
    } finally {
      server.stopSuspend(100, 1000)
    }
  }

  @Test
  fun `client disconnect cancels a suspended handler`() = runBlocking<Unit> {
    val handlerStarted = CompletableDeferred<Unit>()
    val handlerOutcome = CompletableDeferred<String>()
    val server = embeddedServer(CIO, port = 0, host = "127.0.0.1") {
      install(HttpRequestLifecycle) {
        cancelCallOnClose = true
      }
      routing {
        post("/slow") {
          handlerStarted.complete(Unit)
          try {
            delay(30.seconds) // long enough that only cancellation can complete the outcome within the await window below
            handlerOutcome.complete("completed")
            call.respondText("pong")
          } catch (cause: CancellationException) {
            handlerOutcome.complete("cancelled")
            throw cause
          }
        }
      }
    }
    server.startSuspend(wait = false)
    try {
      val port = server.engine.resolvedConnectors().single().port
      Socket("127.0.0.1", port).use { socket ->
        // keep-alive request: the disconnect below must be the only close signal the engine sees
        socket.getOutputStream().sendRequestWithheldBody(connectionClose = false) {
          handlerStarted.await()
        }
      } // socket close = real client disconnect while the handler is suspended
      val outcome = withTimeoutOrNull(10.seconds) { handlerOutcome.await() } ?: "still suspended after 10s"
      assertEquals(
        "cancelled",
        outcome,
        "cancelCallOnClose = true must cancel the suspended handler on a real client disconnect",
      )
    } finally {
      server.stopSuspend(100, 1000)
    }
  }

  /** Sends a POST whose body is withheld until [beforeBody] returns, pinning the engine in its request-body read. */
  private suspend fun OutputStream.sendRequestWithheldBody(connectionClose: Boolean, beforeBody: suspend () -> Unit) {
    val body = """{"key":"value"}""".toByteArray()
    write(
      (
        "POST /slow HTTP/1.1\r\n" +
          "Host: localhost\r\n" +
          "Content-Type: application/json\r\n" +
          "Content-Length: ${body.size}\r\n" +
          (if (connectionClose) "Connection: close\r\n" else "") +
          "\r\n"
        ).toByteArray()
    )
    flush()
    beforeBody()
    write(body)
    flush()
  }
}

dependencies {
  implementation("io.ktor:ktor-server-core:3.4.1")   // or 3.5.1
  implementation("io.ktor:ktor-server-cio:3.4.1")    // or 3.5.1
  testImplementation("org.jetbrains.kotlin:kotlin-test-junit5")
  testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine:5.14.1")
}

CIO: mapToKtor unwraps non-timeout exceptions to their cause

Make quality parameter case-insensitive

OkHttp: Cancelling a request can close the response body on the Android main thread

CIO: "Failed to parse HTTP response: unexpected EOF" when pipelining is on

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

We found out there is unexpected EOF error with jvm ByteChannel in ktor 2.3.*, when we enable pipelining of engine

I can reproduce the error by below code by calling GET http://btse.localhost:8080/test/1, but in 2.2.4 is working fine. please check.

What we expect we should not have any error when calling the API with jackson.

// my service level
class Test2Service : KoinComponent {

    val testClient = HttpClient(CIO) {
        install(ContentNegotiation) {
            jackson()
        }

        engine {
            pipelining = true
        }
    }

    fun test2(input: String): TestData {
        return TestData(input)
    }

    @OptIn(InternalAPI::class)
    suspend fun test3(input: Int): String {
        return testClient.get("http://localhost:8080/hi/$input")
            .content.readUTF8Line(8192).toString()
    }
}


// my routing level
fun Application.configureRouting() {

    routing {
        get("/hi/{random}") {
            call.response.header("Content-Type", "application/json")
            val random = call.parameters["random"] ?: "test"
            call.respond(Test2Service().test2(random))
        }

        get("/test/{number}") {
            call.response.header("Connection", "keep-alive")
            val number = call.parameters["number"]?.toIntOrNull() ?: 1
            call.respond(Test2Service().test3(number))
        }
    }
}

// application server
fun main() {
    embeddedServer(Netty, port = 8080, host = "0.0.0.0") {
        startKoin {
            install(ContentNegotiation) {
                jackson()
            }

        }
        configureRouting()
    }.start(wait = true)
}

Error response (2.3.*)

java.io.EOFException: Failed to parse HTTP response: unexpected EOF
	at io.ktor.client.engine.cio.ConnectionPipeline$responseHandler$1.invokeSuspend(ConnectionPipeline.kt:77)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
	at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.kt:115)
	at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:100)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:584)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:793)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:697)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:684)

Successful in 2.2.4

Curl: Requests leak curl_slist and response StableRef

CIO server: request handler can leak when idle timeout cancels a claimed response

Darwin CertificatePinner over-releases borrowed Core Foundation references

CIO: pipelining corrupts requests with non-empty bodies

OpenAPI: "has no continuation" AssertionError when a suspend call inside a sealed-type branch reads the smart-cast value

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

When OpenAPI generation is enabled (ktor { openApi { enabled = true } }, with codeInferenceEnabled left at its default true), compileKotlin fails with an internal compiler error.

Assertion

e: org.jetbrains.kotlin.backend.common.BackendException: Backend Internal error: Exception during IR lowering
File being compiled: .../src/main/kotlin/Repro.kt
The root cause java.lang.AssertionError was thrown at: org.jetbrains.kotlin.backend.jvm.lower.AddContinuationLoweringKt.retargetToSuspendView(AddContinuationLowering.kt:497)

Caused by: java.lang.AssertionError: FUN LOCAL_FUNCTION_FOR_LAMBDA name:reproRoutes$lambda$0$0 visibility:private modality:FINAL <> ($this_get:io.ktor.server.routing.RoutingContext, <this>:io.ktor.openapi.Responses.Builder) returnType:kotlin.Unit? in file Repro.kt has no continuation; can't call FUN name:authorizeAdmin visibility:public modality:FINAL <> (call:io.ktor.server.application.ApplicationCall) returnType:<root>.AuthorizationResult [suspend]

The receiver of the failing lambda is io.ktor.openapi.Responses.Builder, which does not exist in the source — it is generated by the OpenAPI compiler plugin. A user-level suspend call (authorizeAdmin) ends up inside that generated, non-suspend lambda, which therefore has no continuation.

Reproducer

build.gradle.kts:

plugins {
    kotlin("jvm") version "2.4.10"
    id("io.ktor.plugin") version "3.5.1"
}
repositories { mavenCentral() }
kotlin { jvmToolchain(17) }
dependencies {
    implementation("io.ktor:ktor-server-core:3.5.1")
    implementation("io.ktor:ktor-server-netty:3.5.1")
}
ktor { openApi { enabled = true } }

src/main/kotlin/Repro.kt:

import io.ktor.http.HttpStatusCode
import io.ktor.server.application.ApplicationCall
import io.ktor.server.response.respond
import io.ktor.server.routing.Route
import io.ktor.server.routing.get

sealed class AuthorizationResult {
    data object Success : AuthorizationResult()

    data class Failure(val statusCode: HttpStatusCode, val message: String) : AuthorizationResult()
}

suspend fun withAuthorization(
    call: ApplicationCall,
    block: suspend () -> AuthorizationResult,
): Boolean {
    val result = block()
    if (result is AuthorizationResult.Failure) {
        // suspend call AND a read of the smart-cast value, in the same branch
        call.respond(result.statusCode, result.message)
        return false
    }
    return true
}

suspend fun authorizeAdmin(call: ApplicationCall): AuthorizationResult {
    call.respond(HttpStatusCode.OK, "checked")
    return AuthorizationResult.Success
}

fun Route.reproRoutes() {
    get("/repro") {
        if (!withAuthorization(call) { authorizeAdmin(call) }) {
            return@get
        }
        call.respond(HttpStatusCode.OK, "ok")
    }
}

Then:

./gradlew compileKotlin --rerun-tasks

Trigger, narrowed one variable at a time

The crash needs a suspend function that takes a suspend () -> T parameter where T is a sealed class, and whose body contains both a read of the smart-cast value and a suspend call inside the same type-check branch. Whether the branch is written as if or when makes no difference.

body of `withAuthorization`	result
suspend call outside the branch	compiles
suspend call inside the branch, literal arguments only	compiles
read of the smart-cast value, suspend call outside the branch	compiles
`call.respond(result.statusCode, result.message)` inside the branch	crash
the same, written as `when (result) { is Failure -> ... }`	crash
the same, but the members hoisted into locals before the call	crash

Versions tried

Ktor	Kotlin	result
3.5.1	2.4.10	crash
3.5.1	2.4.0	crash
3.5.1 with `ktor-compiler-plugin` substituted to 3.5.2	2.4.10 / 2.4.0	crash
3.4.3	2.3.21	crash
3.4.3	2.3.0 (the version its compiler plugin is built against)	crash
3.4.1	2.3.0	crash
3.4.0	2.3.21	different error, `getLOCAL_FUNCTION_FOR_LAMBDA` (KTOR-9370)
3.3.3	2.3.21	`openApi { enabled }` does not exist yet

Gradle 8.14.5, JVM toolchain 17, macOS 15 (arm64).

Impact

This is the shape of an ordinary authorization guard, so in our server (~213 endpoints) every route goes through it and OpenAPI generation cannot be enabled at all. We could not find a source-level workaround that keeps the sealed-result design.

Possibly related

KTOR-9389, KTOR-9392, KTOR-9443 — the same family (code inference producing invalid IR), but different symptoms.
Setting codeInferenceEnabled = false avoids this crash, but the plugin then fails on the test source sets with IrGenerationExtensionException: Parent of element (CLASS ... ) is not initialized, because CompilerPlugin.isApplicable only checks openApi.enabled and so the plugin is applied to every compilation. Happy to file that separately if it is not the same root cause.

OkHttp: duplex streaming does not release the connection after the request completes

`DigestAuthProvider` cannot be initialized with a congested `Dispatchers.Default` pool

Outdated KDoc for AuthProvider.refreshToken method

Application lifecycle events affect other reload generations

The new DI scope is cancelled during hot reload

Unnecessary blocking in OutputStream wrapper

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

We have mostly mitigated the request blocking of the OutputStream wrapper by introducing a separate IO dispatcher, but we can further avoid blocking by writing directly to our in-memory buffer and only blocking as flushes are needed.

"DefaultDispatcher-worker-2" #152 [155] daemon prio=5 os_prio=0 cpu=59.06ms elapsed=4297.51s tid=0x00007f9e297756e0 nid=155 waiting on condition  [0x00007f9e2952a000]
   java.lang.Thread.State: TIMED_WAITING (parking)
        at jdk.internal.misc.Unsafe.park(java.base@23.0.2/Native Method)
        - parking to wait for  <0x00000000ed25a1c0> (a kotlinx.coroutines.BlockingCoroutine)
        at java.util.concurrent.locks.LockSupport.parkNanos(java.base@23.0.2/LockSupport.java:269)
        at kotlinx.coroutines.BlockingCoroutine.joinBlocking(Builders.kt:98)
        at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking(Builders.kt:69)
        at kotlinx.coroutines.BuildersKt.runBlocking(Unknown Source)
        at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking$default(Builders.kt:47)
        at kotlinx.coroutines.BuildersKt.runBlocking$default(Unknown Source)
        at io.ktor.utils.io.jvm.javaio.BlockingKt$toOutputStream$1.close(Blocking.kt:67)
        at kotlin.io.CloseableKt.closeFinally(Closeable.kt:56)
        at io.ktor.http.content.OutputStreamContent$writeTo$2.invokeSuspend(OutputStreamContent.kt:27)
        at io.ktor.http.content.OutputStreamContent$writeTo$2.invoke(OutputStreamContent.kt)
        at io.ktor.http.content.OutputStreamContent$writeTo$2.invoke(OutputStreamContent.kt)
        at io.ktor.http.content.BlockingBridgeKt$withBlockingAndRedispatch$2.invokeSuspend(BlockingBridge.kt:45)
        at io.ktor.http.content.BlockingBridgeKt$withBlockingAndRedispatch$2.invoke(BlockingBridge.kt)
        at io.ktor.http.content.BlockingBridgeKt$withBlockingAndRedispatch$2.invoke(BlockingBridge.kt)
        at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturn(Undispatched.kt:43)
        at kotlinx.coroutines.BuildersKt__Builders_commonKt.withContext(Builders.common.kt:166)
        at kotlinx.coroutines.BuildersKt.withContext(Unknown Source)
        at io.ktor.http.content.BlockingBridgeKt.withBlockingAndRedispatch(BlockingBridge.kt:44)
        at io.ktor.http.content.BlockingBridgeKt.withBlocking(BlockingBridge.kt:32)
        at io.ktor.http.content.OutputStreamContent.writeTo(OutputStreamContent.kt:24)
        at io.ktor.http.content.CompressedWriteChannelResponse$writeTo$2.invokeSuspend(CompressedContent.kt:82)
        at io.ktor.http.content.CompressedWriteChannelResponse$writeTo$2.invoke(CompressedContent.kt)
        at io.ktor.http.content.CompressedWriteChannelResponse$writeTo$2.invoke(CompressedContent.kt)
        at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturn(Undispatched.kt:43)
        at kotlinx.coroutines.BuildersKt__Builders_commonKt.withContext(Builders.common.kt:157)
        at kotlinx.coroutines.BuildersKt.withContext(Unknown Source)
        at io.ktor.http.content.CompressedWriteChannelResponse.writeTo(CompressedContent.kt:80)
        at io.ktor.server.engine.BaseApplicationResponse$respondWriteChannelContent$2$1.invokeSuspend(BaseApplicationResponse.kt:176)
        at io.ktor.server.engine.BaseApplicationResponse$respondWriteChannelContent$2$1.invoke(BaseApplicationResponse.kt)
        at io.ktor.server.engine.BaseApplicationResponse$respondWriteChannelContent$2$1.invoke(BaseApplicationResponse.kt)
        at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturn(Undispatched.kt:43)
        at kotlinx.coroutines.BuildersKt__Builders_commonKt.withContext(Builders.common.kt:166)
        at kotlinx.coroutines.BuildersKt.withContext(Unknown Source)
        at io.ktor.server.engine.BaseApplicationResponse.respondWriteChannelContent$suspendImpl(BaseApplicationResponse.kt:175)
        at io.ktor.server.engine.BaseApplicationResponse.respondWriteChannelContent(BaseApplicationResponse.kt)
        at io.ktor.server.engine.BaseApplicationResponse.respondOutgoingContent$suspendImpl(BaseApplicationResponse.kt:132)
        at io.ktor.server.engine.BaseApplicationResponse.respondOutgoingContent(BaseApplicationResponse.kt)
        at io.ktor.server.netty.NettyApplicationResponse.respondOutgoingContent$suspendImpl(NettyApplicationResponse.kt:37)
        at io.ktor.server.netty.NettyApplicationResponse.respondOutgoingContent(NettyApplicationResponse.kt)
        at io.ktor.server.engine.BaseApplicationResponse$Companion$setupSendPipeline$1.invokeSuspend(BaseApplicationResponse.kt:319)
        at io.ktor.server.engine.BaseApplicationResponse$Companion$setupSendPipeline$1.invoke(BaseApplicationResponse.kt)
        at io.ktor.server.engine.BaseApplicationResponse$Companion$setupSendPipeline$1.invoke(BaseApplicationResponse.kt)
        at io.ktor.util.pipeline.PipelineJvmKt.pipelineStartCoroutineUninterceptedOrReturn(PipelineJvm.kt:15)
        at io.ktor.util.pipeline.SuspendFunctionGun.loop(SuspendFunctionGun.kt:131)
        at io.ktor.util.pipeline.SuspendFunctionGun.proceed(SuspendFunctionGun.kt:89)
        at io.ktor.util.pipeline.SuspendFunctionGun.proceedWith(SuspendFunctionGun.kt:99)
        at io.ktor.server.engine.DefaultTransformKt$installDefaultTransformations$1.invokeSuspend(DefaultTransform.kt:29)
        at io.ktor.server.engine.DefaultTransformKt$installDefaultTransformations$1.invoke(DefaultTransform.kt)
        at io.ktor.server.engine.DefaultTransformKt$installDefaultTransformations$1.invoke(DefaultTransform.kt)
        at io.ktor.util.pipeline.PipelineJvmKt.pipelineStartCoroutineUninterceptedOrReturn(PipelineJvm.kt:15)
        at io.ktor.util.pipeline.SuspendFunctionGun.loop(SuspendFunctionGun.kt:131)
        at io.ktor.util.pipeline.SuspendFunctionGun.proceed(SuspendFunctionGun.kt:89)
        at io.ktor.util.pipeline.SuspendFunctionGun.execute$ktor_utils(SuspendFunctionGun.kt:109)
        at io.ktor.util.pipeline.Pipeline.execute(Pipeline.kt:79)
        at io.ktor.server.application.PipelineCall$DefaultImpls.respond(PipelineCall.kt:106)
        at io.ktor.server.routing.RoutingPipelineCall.respond(RoutingPipelineCall.kt:20)
        at io.ktor.server.routing.RoutingCall.respond(RoutingNode.kt:229)
        at io.ktor.server.response.ApplicationResponseFunctionsJvmKt.respondOutputStream(ApplicationResponseFunctionsJvm.kt:135)
        at org.jetbrains.kotlin.diogen.server.ProgramKt.handleDomainCall(Program.kt:345)
        at org.jetbrains.kotlin.diogen.server.ProgramKt.access$handleDomainCall(Program.kt:1)
        at org.jetbrains.kotlin.diogen.server.ProgramKt$main$1$12$7$1$1.invokeSuspend(Program.kt:277)
        at org.jetbrains.kotlin.diogen.server.ProgramKt$main$1$12$7$1$1.invoke(Program.kt)
        at org.jetbrains.kotlin.diogen.server.ProgramKt$main$1$12$7$1$1.invoke(Program.kt)
        at org.jetbrains.kotlin.diogen.server.Site.withZip(Program.kt:390)
        at org.jetbrains.kotlin.diogen.server.ProgramKt$main$1$12$7$1.invokeSuspend(Program.kt:276)
        at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
        at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:100)
        at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.kt:113)
        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)

OpenAPI: reflection schema inference produces incorrect discriminator mapping for Jackson-annotated and nested sealed hierarchies

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

Description

When using Jackson annotations to declare serialization and deserialization of sealed class hierarchies, there is a mismatch between the actual JSON (de/)serialization and the generated OpenAPI specification. You can specify both the property name of the discriminator field (which I believe is fixed in KTOR-9591) and the discriminator value each subtype is mapped to. It would be nice if the SchemaReflectionAdapter had a way to override this behavior. In addition, there is an issue with how nested hierarchies are represented where an intermediary sealed interface/class gets its own discriminator mapping.

Steps to reproduce

import Shape.Circle
import Shape.Triangle
import com.fasterxml.jackson.annotation.JsonSubTypes
import com.fasterxml.jackson.annotation.JsonTypeInfo

@JsonTypeInfo(use = JsonTypeInfo.Id.NAME, include = JsonTypeInfo.As.PROPERTY, property = "kind")
@JsonSubTypes(
    JsonSubTypes.Type(value = Circle::class, name = "CIRCLE"),
    JsonSubTypes.Type(value = Shape.Square::class, name = "SQUARE"),
    JsonSubTypes.Type(value = Triangle.Equilateral::class, name = "EQUILATERAL_TRIANGLE"),
    JsonSubTypes.Type(value = Triangle.Isosceles::class, name = "ISOSCELES_TRIANGLE"),
    JsonSubTypes.Type(value = Triangle.Scalene::class, name = "SCALENE_TRIANGLE"),
)
sealed interface Shape {
    data class Circle(val radius: Int) : Shape
    data class Square(val length: Int) : Shape

    sealed interface Triangle : Shape {
        data class Equilateral(val length: Int): Triangle
        data class Isosceles(val legsLength: Int, val oddLength: Int) : Triangle
        data class Scalene(val length1: Int, val length2: Int, val length3: Int) : Triangle
    }
}

Expose Shape and Triangle as response bodies in separate endpoints.

Expected behavior

"Shape": {
    "type": "object",
    "title": "Shape",
    "oneOf": [
      {
        "$ref": "#/components/schemas/Circle"
      },
      {
        "$ref": "#/components/schemas/Square"
      },
      {
        "$ref": "#/components/schemas/Triangle"
      }
    ],
    "discriminator": {
      "propertyName": "type",
      "mapping": {
        "CIRCLE": "#/components/schemas/Circle",
        "SQUARE": "#/components/schemas/Square",
        "EQUILATERAL_TRIANGLE": "#/components/schemas/Equilateral",
        "ISOSCELES_TRIANGLE": "#/components/schemas/Isosceles",
        "SCALENE_TRIANGLE": "#/components/schemas/Scalene"
      }
    }
}

I'm unsure if the oneOf array would have to be expanded with each concrete type, or if it is valid with a $ref to a schema (Triangle) that is also a oneOf type.

Actual behavior

"Shape": {
  "type": "object",
  "title": "Shape",
  "oneOf": [
    {
      "$ref": "#/components/schemas/Circle"
    },
    {
      "$ref": "#/components/schemas/Square"
    },
    {
      "$ref": "#/components/schemas/Triangle"
    }
  ],
  "discriminator": {
    "propertyName": "type",
    "mapping": {
      "no.nav.pensjon.brev.skribenten.openapi.OpenApiSpecTest.Shape.Circle": "#/components/schemas/Circle",
      "no.nav.pensjon.brev.skribenten.openapi.OpenApiSpecTest.Shape.Square": "#/components/schemas/Square",
      "no.nav.pensjon.brev.skribenten.openapi.OpenApiSpecTest.Shape.Triangle": "#/components/schemas/Triangle"
    }
  }
}

Suggested fix

The discriminator mapping name is easy enough to change by adding a new method to the SchemaReflectionAdapter interface, e.g. getDiscriminatorMappingName. The nested hierarchy problem would involve climbing down the sealedSubclasses-tree of the kClass.isSealed case in ReflectionJsonSchemaInference::buildSchemaInternal.

Digest Auth: URI and HA2 are empty for a URL without a path

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

Digest client auth: uri and HA2 are empty for a URL without a path, so authentication always fails

Reported by the dav4jvm project (WebDAV/CalDAV/CardDAV library, used by the DAVx5 Android app). We hit this with ktor-client-auth 3.5.1 and currently work around it in our own AuthProvider; we would like to drop that workaround.

Affected component: ktor-client-auth (client-side DigestAuthProvider)
Affected versions: 3.5.1 (current code, unchanged for a long time)

Overview

When a request URL has no path — e.g. https://example.com, without the trailing slash — DigestAuthProvider computes both the uri auth parameter and HA2 from Url.fullPath, which is the empty string in that case. It therefore sends uri="" and hashes over "GET:", while the request target actually put on the wire is /.

The server, which computes HA2 over the request target it received (/), calculates a different response and rejects the request. Digest auth can never succeed for such a URL.

References:

RFC 9112, section 3.2.1 — "If the target URI's path component is empty, the client MUST send / as the path within the origin-form of request-target."
RFC 7616, section 3.4 — the uri directive is "The Effective Request URI […] of the HTTP request; duplicated here because proxies are allowed to change the request target."
RFC 7616, section 3.4.3 — A2 = Method ":" request-uri.

Steps to reproduce

Kotlin/JVM, ktor-client-auth + ktor-client-mock 3.5.1, JUnit 4:

@Test
fun reproduce() = runTest {
    val engine = MockEngine { request ->
        if (request.headers[HttpHeaders.Authorization] == null)
            respond(
                content = "",
                status = HttpStatusCode.Unauthorized,
                headers = headersOf(
                    HttpHeaders.WWWAuthenticate,
                    """Digest realm="test", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", qop="auth", algorithm=MD5"""
                )
            )
        else
            respond(content = "OK", status = HttpStatusCode.OK)
    }
    val client = HttpClient(engine) {
        install(Auth) {
            digest {
                credentials { DigestAuthCredentials(username = "user", password = "password") }
            }
        }
    }

    // note the missing trailing slash
    client.get("https://example.com")

    for (request in engine.requestHistory)
        println("--> ${request.method.value} [${request.url}] Authorization: ${request.headers[HttpHeaders.Authorization]}")
}

Result

Output of the reproducer:

--> GET [https://example.com] Authorization: null
--> GET [https://example.com] Authorization: Digest realm="test", username="user",
    nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", cnonce="f4939f273be23cec7523ed784d5cd1a2",
    response="4fce4e2c78fd64a3c88c590e662304c2", uri="", qop=auth, nc=00000001, algorithm=MD5

Actual result: uri="", and the response is computed with HA2 = MD5("GET:").

Expected result: uri="/", and HA2 = MD5("GET:/").

The response value confirms which HA2 was used (HA1 = MD5("user:test:password"), qop=auth, nc=00000001 and the cnonce from the header above):

HA2 over	resulting `response`
`GET:`	`4fce4e2c78fd64a3c88c590e662304c2` ← what ktor sends
`GET:/`	`e44ed87bf661a5c8ff6af6eacb448bae` ← what a server computes

Why the expected result is / and not "":

Per RFC 9112 §3.2.1 the client MUST send / as the request target when the target URI's path is empty, and ktor clients do: Url.toString() produces https://example.com, and the engine turns that into GET / HTTP/1.1. For the OkHttp engine this happens in OkHttpEngine.kt, which passes url.toString() to OkHttp, and OkHttp normalizes the empty path to /.
Per RFC 7616 §3.4/§3.4.3 both the uri directive and HA2 must use that same request target. So they must be /, not "" — an empty digest-uri-value also isn't a valid request-target to begin with.

Suspected cause and possible fix

DigestAuthProvider.addRequestHeaders() uses url.fullPath in two places:

val end = makeDigest("$methodName:${url.fullPath}").toHexString()   // line 187
…
this["uri"] = url.fullPath.quote()                                  // line 205

and Url.fullPath returns "" for an empty path, because appendUrlFullPath() only prepends the / when encodedPath.isNotBlank().

Two options:

Local fix in DigestAuthProvider: use the request target that is actually sent, e.g. val requestUri = url.fullPath.ifEmpty { "/" }, for both line 187 and line 205.
Fix Url.fullPath: have it return / for an empty path, since it models "the path that goes on the wire" and RFC 9112 §3.2.1 requires / there. This would also cover any other place that builds a request target from fullPath (we did not audit the engines for this).

We would prefer option 2 if fullPath is indeed meant to be the request target, but option 1 already fixes the authentication failure.

Possibly related issues

Not duplicates as far as we can tell, but in the same area: KTOR-7578, KTOR-4318, KTOR-7869 (RFC 7616 conformance of the client digest computation) and KTOR-9620.

Our workaround (for reference)

We normalize the path before delegating to DigestAuthProvider, so that its fullPath is non-empty:

private fun HttpRequestBuilder.workaroundKtorEmptyDigestUri() {
    if (url.encodedPath.isEmpty())
        url.encodedPath = "/"
}

See bitfireAT/dav4jvm#219.

Character classification in ktor-http hot paths uses boxed Set<Char> lookups and per-symbol encoder allocations

OpenAPI UI (ktor-server-openapi) does not support OpenAPI spec 3.1.*

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

swagger generates openapi v3.1.1 by default

Code example:
main.kt

package com.example

import io.ktor.http.HttpHeaders
import io.ktor.http.HttpStatusCode
import io.ktor.serialization.kotlinx.json.json
import io.ktor.server.application.Application
import io.ktor.server.application.install
import io.ktor.server.plugins.contentnegotiation.ContentNegotiation
import io.ktor.server.plugins.cors.routing.CORS
import io.ktor.server.plugins.openapi.openAPI
import io.ktor.server.plugins.swagger.swaggerUI
import io.ktor.server.request.receive
import io.ktor.server.response.respond
import io.ktor.server.response.respondText
import io.ktor.server.routing.get
import io.ktor.server.routing.post
import io.ktor.server.routing.routing
import io.ktor.server.util.getValue
import io.swagger.codegen.v3.generators.html.StaticHtml2Codegen
import kotlinx.serialization.Serializable
import kotlinx.serialization.json.Json

@Serializable
data class Customer(val id: Int, val firstName: String, val lastName: String)

fun Application.main() {
    val customerStorage = mutableListOf<Customer>()
    customerStorage.addAll(
        arrayOf(
            Customer(1, "Jane", "Smith"),
            Customer(2, "John", "Smith")
        )
    )

    install(ContentNegotiation) {
        json(Json {
            prettyPrint = true
            isLenient = true
        })
    }
    install(CORS) {
        anyHost()
        allowHeader(HttpHeaders.ContentType)
    }
    routing {
        get("/customer/{id}") {
            val id: Int by call.parameters
            val customer: Customer = customerStorage.find { it.id == id }!!
            call.respond(customer)
        }

        post("/customer") {
            val customer = call.receive<Customer>()
            customerStorage.add(customer)
            call.respondText("Customer stored correctly", status = HttpStatusCode.Created)
        }

        swaggerUI(path = "swagger", swaggerFile = "openapi/documentation.yaml") {
            version = "4.15.5"
        }
        openAPI(path="openapi", swaggerFile = "openapi/documentation.yaml") {
            codegen = StaticHtml2Codegen()
        }
    }
}

build.gradle.kts

plugins {
    alias(libs.plugins.kotlin.jvm)
    alias(ktorLibs.plugins.ktor)
    id("org.jetbrains.kotlin.plugin.serialization") version "2.4.0"
}

group = "com.example"
version = "1.0.0-SNAPSHOT"

application {
    mainClass = "io.ktor.server.netty.EngineMain"
}

kotlin {
    jvmToolchain(25)
}

ktor {
    openApi {
        enabled = true
        codeInferenceEnabled = true
        onlyCommented = false
    }
}

dependencies {
    implementation(ktorLibs.server.config.yaml)
    implementation(ktorLibs.server.core)
    implementation(ktorLibs.server.netty)
    implementation(ktorLibs.server.openapi)
    implementation(ktorLibs.server.routingOpenapi)
    implementation(libs.logback.classic)
    implementation(ktorLibs.server.contentNegotiation)
    implementation(ktorLibs.serialization.kotlinx.json)
    implementation(ktorLibs.server.cors)
    implementation(ktorLibs.server.swagger)
    implementation("io.swagger.codegen.v3:swagger-codegen-generators:1.0.62")

    testImplementation(kotlin("test"))
    testImplementation(ktorLibs.server.testHost)
}

As I understood, it doesn't work on openapi 3.1.1 (work on 3.0.3)

documentation.yaml (working):

openapi: "3.0.3"
info:
  title: "JSON API sample"
  description: "A JSON API that allows you to view and add customers"
  version: "1.0.0"
servers:
  - url: "http://0.0.0.0:8080"
paths:
  /customer:
    post:
      description: "Creates a new customer"
      requestBody:
        description: "A JSON object containing customer information"
        required: true
        content:
          application/json:
            schema:
              $ref: "#/components/schemas/Customer"
      responses:
        "201":
          description: "Created"
          content:
            text/plain:
              schema:
                type: "string"
              examples:
                Example#1:
                  value: "Customer stored correctly"
  /customer/{id}:
    get:
      description: "Returns a customer by its ID"
      parameters:
        - name: "id"
          in: "path"
          required: true
          schema:
            type: "string"
      responses:
        "200":
          description: "OK"
          content:
            '*/*':
              schema:
                $ref: "#/components/schemas/Customer"
components:
  schemas:
    Customer:
      type: "object"
      properties:
        id:
          type: "integer"
          format: "int32"
        firstName:
          type: "string"
        lastName:
          type: "string"

documentation.yaml (not working):

openapi: 3.1.1
info:
  title: Untitled API
  version: 1.0.0
paths:
  /customer/{id}:
    get:
      summary: ""
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: integer
      responses:
        "200":
          description: ""
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Customer"
  /customer:
    post:
      summary: ""
      requestBody:
        content:
          application/json:
            schema:
              $ref: "#/components/schemas/Customer"
      responses:
        "201":
          description: ""
          content:
            text/plain: {}
webhooks: {}
components:
  schemas:
    Customer:
      type: object
      title: Customer
      required:
        - id
        - firstName
        - lastName
      properties:
        id:
          type: integer
        firstName:
          type: string
        lastName:
          type: string

Netty HTTP/3: user handler code is dispatched on the QUIC event loop — one blocking handler freezes the entire HTTP/3 listener (callEventGroup / pinnedCallExecutor not used)

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

Affected versions

Unreleased: main (3.6.0-SNAPSHOT), verified at commit baec59c0b0159c685ef46cb638da3711bb58e67b
(2026-07-16, after the KTOR-9712 merge). HTTP/3 support for the Netty engine was introduced in
PR ktorio/ktor#5527.

Problem

Since KTOR-9542, HTTP/1 and HTTP/2 dispatch application handler code onto an executor pinned
from callEventGroup, keeping user code off the Netty I/O threads:

HTTP/1: NettyHttp1Handler.kt:177 — CurrentContext(context, callExecutor)
HTTP/2: NettyHttp2Handler.kt:128-L131 — pinnedCallExecutor(context, callEventGroup)
The intent is documented in PinnedCallExecutor.kt.

The new HTTP/3 handler does neither. NettyHttp3Handler does not receive callEventGroup at
all, and startHttp3 builds the call context with the single-argument CurrentContext:

NettyHttp3Handler.kt:102:
staticCallContext + NettyDispatcher.CurrentContext(context) + callJob
CIO.kt:102-L105:
the single-argument overload defaults to executor = context.executor() — the KDoc itself
notes this executor "runs I/O work".
NettyHttp3Handler.kt:114:
the call coroutine is also launched via context.executor().execute { ... }.

So every resumption of the application coroutine is dispatched onto the QUIC stream's event
loop. This is aggravated by the HTTP/3 topology: each SSL connector binds a single
DatagramChannel registered on workerEventGroup
(NettyApplicationEngine.kt, createHttp3Bootstrap),
and netty-codec-quic drives all QUIC connections and streams of that connector on that one
channel's event loop. Any blocking user code (JDBC, file IO, CPU-heavy serialization)
therefore stalls not just its own stream but the whole HTTP/3 listener — including QUIC
handshakes of brand-new, unrelated connections.

The same application code behaves fine over HTTP/1/2 on the same server, which makes this a
very confusing performance trap once HTTP/3 is enabled.

Reproducer

Attached NettyHttp3CallExecutorTest.kt (drop into
ktor-server/ktor-server-netty/jvm/test/io/ktor/tests/server/netty/). The test
blocking user code on one HTTP3 connection must not stall other connections:

handler /block signals a latch, then does Thread.sleep(1500);
connection A fires GET /block without awaiting the response; the test waits on the latch,
so the server is now inside the blocking section;
a brand-new QUIC connection B (fresh handshake) issues GET /instant.

Expected (and asserted): B completes in roughly baseline time. Actual on main: B takes
~the full blocking duration, because its handshake + request can't be processed until the
event loop thread returns from the handler's Thread.sleep. The test also prints the handler
thread name, which is the event-loop thread.

Observed on main @ baec59c0:

[repro] HTTP/3 handler thread: eventLoopGroupProxy-3-1 @call-handler#10   // netty worker (I/O) event loop
[repro] fresh connection + GET /instant with idle server: 56ms
[repro] fresh connection + GET /instant while another connection's handler blocks: 1517ms   // ≈ the full 1500 ms Thread.sleep

With the fix (pinned executor from callEventGroup, mirroring HTTP/1/2):

[repro] HTTP/3 handler thread: eventLoopGroupProxy-4-1 @call-handler#10   // call event group executor
[repro] fresh connection + GET /instant with idle server: 49ms
[repro] fresh connection + GET /instant while another connection's handler blocks: 49ms   // no stall

Suggested fix

Mirror the HTTP/1/2 model: pass callEventGroup into NettyHttp3Handler (via
NettyHttp3ChannelInitializer / NettyHttp3RequestStreamInitializer) and build the call
context with NettyDispatcher.CurrentContext(context, pinnedCallExecutor(context, callEventGroup)),
launching the call coroutine on that executor as startHttp2 does.

KTOR-9542 (introduced the pinned call executor for HTTP/1/2)
KTOR-9712 (HTTP/3: per-connection Http3ServerConnectionHandler — merged; this reproducer
relies on it, since it needs a second concurrent QUIC connection)