Hello everyone,

first and foremost, thank you for the awesome framework that Netty is.

As a downstream user, the OpenDaylight project has recently started using netty-codec-http(2) to supplant our use of Jetty/Jersey/PAX-Web to provide an implementation of RESTCONF using Netty -- the key driver being our architecture (which calls for all protocols to be implemented on top of Netty) and reduction of dependencies (for security and footprint reasons).

Our aim is to provide a RESTCONF server over HTTP/1.1 and HTTP/2 using Netty, while hiding the protocol differences from high-level components.

While our implementation is far from being correct or complete, we find ourselves implementing a framework on top of Netty far beyond what we envisioned. In general, this is okay as it is a failure of exploration on our part. What is not okay is that we are building a bespoke framework for functionality that seems to have broader applicability.

The reason for this is that unlike other components at this layer, HTTP transport combines multiple OSI layers: Transport, Session, Presentation and Application.

While Netty provides (very reasonable!) building blocks for L4-L6, it seems to be lacking an independent abstraction of L7, e.g. a framework users would plug into L7 HTTP semantics without caring about the L4-L7 differences between HTTP/1.1, HTTP/2 or (eventually) HTTP/3.

I understand that this is beyond Netty's scope, but the framework we have brewing seems to be generally useful in a number of areas, ranging from dealing with HTTP request validation, to mapping implemented methods, dealing with server-wide requests and locating and determining the dispatch model for a resource.

There are also further L7 concerns, such as RF6415, which I have not found an open-source equivalent anywhere, thus allowing Netty to lead the way.

From licensing perspective, all the code referenced is copyright-owed by PANTHEON.tech and with my head-of-OSPO hat on, there is absolutely no problem in switching from EPL to whatever Netty needs -- we have this before and are happy to that again. I do not foresee a third party stepping in, but should that happen, I am confident we can reach an amicable agreement.

From technical perspective, we will obviously make whatever changes are needed to suite the Netty project, as long as our downstream requirements are met.

All in all, my question is: given there is equivalent integration (L7) present in Netty today (as far as I have was able to ascertain) would the Netty project be willing to accept this sort of a contribution?