Ktor 3.6.0 estrena autenticación tipada y HTTP/3 experimental en Netty
El framework HTTP de Kotlin añade autenticación tipada con roles y usuarios anónimos, un plugin Oidc para OpenID Connect y soporte HTTP/3 sobre QUIC en el motor Netty, todavía en fase experimental.
Ktor 3.6.0 ya está disponible. El framework de Kotlin para construir servidores y clientes HTTP incorpora autenticación tipada, un plugin Oidc que también trabaja con tipos para OpenID Connect, y HTTP/3 sobre QUIC en el motor Netty. Estas tres piezas llegan marcadas como experimentales, así que quien las active debería asumir que la API puede moverse en versiones posteriores.
La autenticación tipada va más allá del modelo habitual basado en cadenas y predicados. Ahora incluye control de acceso por roles y admite usuarios anónimos, de modo que una ruta puede declarar qué principal espera y qué rol necesita sin construir la comprobación a mano en cada handler. El plugin Oidc tipado cubre el flujo de OpenID Connect con el mismo enfoque, algo que hasta ahora se resolvía con configuración suelta o con librerías de terceros.
Netty, QUIC y los conectores
En el lado del servidor, el motor Netty suma HTTP/3 sobre QUIC de forma experimental. Es el cambio con más implicaciones operativas: QUIC viaja sobre UDP, no sobre TCP, y eso afecta a firewalls, balanceadores y a cómo se mide el tráfico. Si la infraestructura tiene reglas estrictas de puertos o middleboxes que no entienden UDP, activar HTTP/3 no basta con tocar la configuración de Ktor.
Netty también puede servir h2c y HTTP/2 con TLS habilitado en conectores separados. Para quien mantiene despliegues mixtos, donde una parte del tráfico entra en claro por una red interna y otra llega cifrada desde fuera, esto evita tener que montar dos instancias o un proxy delante solo para separar esos dos mundos.
Cambios menores que se notan en el día a día
La versión amplía los tipos admitidos como route handler, lo que da más margen para mantener tipado el resultado de una ruta sin envolverlo a mano. El método receive() acepta ahora valores nulos, un detalle pequeño que elimina ciertos patrones de comprobación previa en los handlers.
El framework además conserva las cabeceras Accept explícitas, en lugar de reescribirlas por su cuenta, algo relevante cuando hay negociación de contenido de por medio o un proxy que decide en función de esa cabecera. Y simplifica los motores de cliente de Kotlin Multiplatform junto con el almacenamiento de la caché HTTP, dos zonas donde la configuración solía ser más verbosa de lo deseable.
Ktor compite en un terreno donde Spring y los frameworks de Node siguen siendo la opción por defecto en muchos equipos. Su baza es Kotlin y, sobre todo, el cliente multiplataforma, que se compila para JVM, nativo y JS. Que la autenticación tipada y HTTP/3 lleguen como experimentales significa que el equipo prefiere soltar la API antes que congelarla. Quien despliegue esto en producción debería fijar la versión exacta y revisar las notas de la release antes de subir de minor, porque el aviso de experimental en Ktor ha precedido históricamente a cambios de firma.
