Internal

This is the default HTTP implementation of genhttp-kt, the port of GenHTTP’s internal engine. It is written in Kotlin and relies only on the JDK, kotlinx.coroutines and the SLF4J API, which keeps the dependencies of your application and the environment it needs to a minimum. This makes it a good choice for embedding a web service into another application (e.g. a desktop application) or hosting a small service as a Docker container. Both genhttp-core and genhttp-full contain it.

import org.genhttp.engine.internal.Host
import org.genhttp.modules.functional.Inline

suspend fun main() {
    Host.create()
        .handler(Inline.create().get { "Hello World!" })
        .run()
}

How It Works

The engine is a port of GenHTTP’s internal engine, built on what the JVM offers today:

• Virtual threads and coroutines. Every endpoint accepts connections on a virtual thread, and every connection is handled as a coroutine on a dispatcher that runs each task on a virtual thread of its own.
• Blocking NIO. Connections are read and written through NIO socket channels in blocking mode: a blocking call only parks a virtual thread, while the JDK does the asynchronous work. This is what makes the blocking stream types of the API (InputStream request bodies, OutputStream sinks) safe to use from suspending handlers. Blocking calls in your handlers are fine for the same reason - long running, CPU heavy work should move to Dispatchers.Default.
• A hardened parser. Requests are parsed by glyph11-kt, a port of the hardened Glyph11 parser, over a contiguous buffer of the connection. Requests exceeding its limits (e.g. 100 header fields, 8 KB per header value or URL) or violating the protocol are answered with an error status, and the connection is closed. Request objects are reused per connection, as in GenHTTP.
• Buffered responses. Responses are serialized into a buffered writer and sent with chunked transfer encoding if the length of their content is not known. Connections are kept alive, and pipelined requests are answered in order.
• TLS with SSLEngine. Secure endpoints encrypt the connection with the SSLEngine of the JDK (TLS 1.2 and 1.3). The certificate is selected per host name the client sends (SNI) by the CertificateProvider of the endpoint, client certificates are checked by its CertificateValidator (see Security).
• Timeouts. A connection is closed if it sends no data for 10 seconds before its first request (or does not complete the TLS handshake within 10 seconds), and after 60 seconds without a request between two requests.

The engine speaks HTTP/1.0 and HTTP/1.1. HTTP/2 and HTTP/3 are not supported - an endpoint bound with HttpProtocols that do not include Http1 cannot be started.

If your handlers rarely block and you are after throughput rather than a minimal set of dependencies, have a look at the Netty engine.