bethibande / nettyhttpframework

A basic http(s) 2.0 library based on netty

NettyHttpServer

A simple http 2 server and client implemented using netty.
A basic http 3 implementation exists, development was stopped though since nettys http 3 implementation is much slower than http 3.

nettyhttpframework's Issues

Path builder, optional path

Make the path of post, delete, get, [...], methods optional, by adding a default value to the parameter. This will allow for easier/cleaner crud builders and prevent redundancy e.g.

server.routes {
    path("/api") {
        path("/comment") {
            get(commentHandler::details)
            post(commentHandler::create)
            patch(commentHandler::edit)
            delete(commentHandler::delete)
        }
    }
}

instead of

server.routes {
    path("/api") {
        get("/comment", commentHandler::details)
        post("/comment", commentHandler::create)
        patch("/comment", commentHandler::edit)
        delete("/comment", commentHandler::delete)
    }
}

Performance and HTTP/2

Performance with netty http-3/quic seems terrible, cpu utilization cannot exceed 10%-20%, looking at some profiling results this seems to be caused by frequent and longlasting native calls since netty/quic is just a wrapper for a native library (quiche).
It should be looked into whether netty/http-2 uses a native library aswell and if not, a basic http-2 version should be implemented to compare performance.

Move Attributes to AttributeList class

Move all netty attribute keys used to store data into a AttributeList class like the one in the execution module.
This will ensure there are no duplicate keys and make it easier to locate key.

Http/2 pure http support

Remove APN handler from http/2 server to support http without tls.

Error handling

Currently there is not error handling, when handling errors, the framework should provide any context possible, e.g. server/client, connection, stream, HttpContext. Server/Client is a must, everything else must only be provided when available.

Http 1 Support

Client connections

Currently the client uses only one connection, this connection is established immediately when a new client instance is created.

1. A client should be able to have multiple connections to the same address
2. A new connection should be established automatically when needed
3. A new connection should be established when the newConnection() method is called
4. Old connections that have timed-out should automatically be removed
5. It has to be possible to retrieve all currently existing connections

Default headers

Add default header values for both client and server

Routing / TreeMap seems to be broken

Rework routing, remove the map entirely and use the routing dsl for filtering requests

Route builder

Route builder like

server.routes {
    get("/status", StatusHandler::handle)
    path("/api", ApiAccessHandler::handle) {
        post("/user", UserHandler::create)
    }
}

Requests will be lost when Connection is closed

When using the RequestExecutor, all queued requests will be lost when the underlying connection is closed.
All requests should be requeue on another connection if this happens.

Request Queue

Requests have to be queued to prevent 1m requests to be executed simultaneously. Executing 1m requests is usually not a big problem, however this will cause all of these 1m requests to not be able to finish thus allocating a lot of memory that cannot be freed until all requests have been completed.

Add a limit of how many requests a connection may execute simultaneously, once this limit is reached all other requests will be queued to be executed once the limit allows it.

HttpContextBase responses

Add response methods to HttpContextBase, these methods will automatically send a response using the given parameters, including header (http-status) and response body (if there is a body)

Http2 push requests

Implement push requests for Http/2

Rewrite server

The Http3Server class and everything around it needs to be rewritten completely. The way it works and its general structure should be closer/identical to the structure of the client.

HttpContextBase

The HttpContextBase has a read-only state and property which are currently unused.
When a context is constructed and the readOnly property is true, the STATE_READ_ONLY state should be applied.
The STATE_READ_ONLY state should prevent any write or writeAndFlush calls using an exception

Client config

I don't think this needs much of a description. The client cannot be configured in any way right now. Make all possible constants configurable and make the SslContext and executor configurable aswell.

Path builder, url encoding

https://github.com/Bethibande/NettyHttpServer/blob/5af4ab46628a96f1d39dbe3d72ab42a6e6cea848/execution/src/main/kotlin/com/bethibande/http/requests/RequestBuilder.kt#L38

Value should be url-encoded

Read & Write API

ctx.write(Writer.forString("Response body"))
ctx.write(Writer.forJson(someObject))

ctx.read(Reader.forString()) { it -> println("String: $it") }
ctx.read(Reader.forObject()) { it -> println("Object: $it") }

val writer = Writer.forString("Response body")
ctx.writeHeader(ctx.headerOf(writer)) /* or */ ctx.writeHeader(HttpStatus.OK, writer)
ctx.write(writer)

class Writer {

  fun contentLength(): Long
  fun contentType(): String  

  fun write(ctx: HttpContextBase)

}

class Reader<T> {

  fun read(ctx: HttpContextBase, contentLength: Long, contentType: String)
  fun result(): T

}

Server push requests

Attributes for Client and Server

Add the AttributeMap interface to Client and Server classes

AbstractHttpHeader to class

Convert the interface AbstractHttpHeader into a class.

Unix Socket support

Reuse/Shared pipeline handlers

Initializing pipelines handlers for each connection/stream requires both cpu time and memory, it's more efficient to reuse the same handler instances for multiple pipelines. However currently handlers store their state in the class instance, e.g. Connection/RequestContext/ResponseContext7Client/Server and more, these values will have to be stored using nettys attribute system.

Before commiting, check if doing this actually causes a notable memory decrease or increase in throughput.

Query Parameters

Currently there is no support for queries, as a matter of fact I'm pretty sure that as of right now, queries would actually stop path resolution and prevent the server from finding/executing the correct server routes.

Obviously this will need to be fixed, also support for reading/writing query parameters in both server and client have to be implemented.

Custom futures

Currently the framework is using netty futures, e.g. DefaultChannelPromise or ChannelProgressiveProvide, these futures seem to be quite expensive to use hence a custom lightweight future implementation may be able to further improve throughput

HttpContextBase responses

• move response methods from HttpContextBase to HttpResponseContext
• add responseAs methods to HttpRequestContext, these methods will read the server response if available and set the result future to the read value or an exception if the status code was an error

Server Config

I don't think this needs much of a description. The client cannot be configured in any way right now. Make all possible constants configurable and make it possible to supply a custom sslcontext

Path variable access

Currently path variables are accessed using their name and the varaible prefix ":". Accessing a variable named "name" now requires to get the value using the key ":name" and not "name", the ":" is not a part of the variable name and just used to indicate a variable in the path hence the correct way to get the variable should be the key "name".

Json support

Add methods to read/write and respond with Objects, add a hook to config used to read/write json objects to allow for usage of pretty much any json framework like gson or jackson

ConnectionManager Connection-Pool

Pool all connections created by the ConnectionManager inside it, if a connection is created without the ConnectionManager using HttpClient.newConnection the ConnectionManager will eventually throw an exception.

Using the pool ensure the ConnectionManager only uses connections created by itself.