Greetings, Ktorians! Now that 3.6.0 has been out ...

# ktor

[Bruce Hamilton]

Greetings, Ktorians!

Now that 3.6.0 has been out for a while, we’re wondering if anyone has tried out any of the new features:
• Typed Authentication
• OpenID Connect
• Default client engines, a.k.a. ktor-client-defaults
• HTTP/3 support in Netty
See the full explanation for these in What’s new in Ktor 3.6.0

Respond in the 🧵 if there’s anything you love or hate in the release, and we’ll ensure your voice is heard!

[rkechols]

I just started up a new Kotlin project after a bit of a hiatus and was very pleasantly surprised when the docs pointed me to ktor-client-engine-defaults. I remember in the past being pretty lost as to what engine to configure, and this just takes care of it completely ♥️

[Paul at Avans Breda]

Hi Bruce / Ktor team,
thanks for your continuous dedication to the Ktor framework!

Here are some experiences from an education point of view:
What was really helpful for us in 3.6.0:
• typed authentication and rbac
• nullable request bodies, receiveMyType?
• default client engines
• the guest lecture of your colleague Simon!

Where we see improvements:
• withRoles currently defaults to requiring all specified roles, some more flexibility (AnyOf vs AllOf) would be nice
• Dedicated Kotlin Toolchain (Amper) documentation. It is still very Gradle oriented.
• Extend documentation with a full example using the Kotlin Toolchain build system and opinionated guide lines.
• Align the different Ktor project templates options

[Bruce Hamilton]

Thanks, all great feedback! We’re working on some better onboarding materials now that hopefully should land pretty soon along with Toolchain examples 🤞

[westnordost]

I have briefly tried out ktor-client-defaults but turned around, I already filed an issue about it. In summary, I am not sure if it is a good idea to obscure to developers which client engine is used (see KTOR-10022). In a nutshell: The different engines have different capabilities, different limitations, different bugs (in the wrapper or, in the engine themselves). Hence, it would make sense for developers to know which engines are used. The different client engines also throw different exceptions on connection errors (which may or may not be an oversight/bug, see KTOR-10027), so currently, it is somewhat required to explicitly know which engines are used on which platform.

If I would want to have one http client engine on all platforms, I would just use CIO on all platforms. And I might, in the future. What I am missing a bit is documentation why (currently?) one wouldn’t always want to do that. (E.g. I think the ktor-client-defaults only uses CIO on Android)

[Bruce Hamilton]

Thanks, we’re looking into unifying our exception handling across all engines atm, so there hopefully be some improvements on that front in 3.7.0. The main reason we want to steer people away from CIO is that it only supports HTTP 1.1 and TLS 1.2 currently. CIO is currently only the default for Android Native because it’s the only engine that works on the platform - most Android applications will use OkHttp via the JVM import.

[westnordost]

ktor-client-android also works on Android, though (ofc).

Regarding TLS 1.2: I by the way switched from the above to ktor-client-cio on Android recently and promptly got issues on Android only because certain servers the app tries to talk with started to only support TLS 1.3 now (ktor-client-android supports TLS 1.3 as far as I know). Basically, the HTTP / TLS capabilities of a multiplatform app are limited by the “weakest link in the chain”. ktor-client-cio not supporting TLS 1.3 becomes ktor-client-defaults not supporting TLS 1.3

[Bruce Hamilton]

The Android engine is JVM only and the default there is OkHttp. CIO is only for Android Native atm, so the workaround would be to build against JVM for now.