Thanks for the request. FYI, we have implemented MTLS on a couple of http4k projects in the past - so you do already can do it at a push. Both involve implementing custom ServerConfig to get the behaviour you want:

1. You can use a RequestContexts and RequestContextKey to attach whatever you want to the request and then access it downstream in a Filter. This isn't particularly neat in terms of server construction because of the bleeding of the RequestContextKey between the ServerConfig and the
2. If you just need the certificate fingerprint for auth, that can be computed and extracted from the certificate and then added to the request as a custom "X-" header.

Thanks for the suggestions!

Currently we are trying to do it by implementing our own HttpHandlerServletAdapter and then rewiring the corresponding up stream code so that we can pass our own HttpHandlerServlet to the Jetty handler, is this what you meant by 2.?

We also tried a less invasive way where we add a ServletFilter to the JettyHandler. However, the issue with this approach was that we had to deal with HttpServletRequest which does not allow us to rewrite the headers. The workaround was to return a subclass of the HttepServletRequestWrapper and override the related getHeader, getHeaders, and getHeaderNames methods to mimic adding of headers. This feels hackish, hence we are trying to find a better way.

It seems that combining this ServletFilter method with RequestContexts is what is suggested in 1 but we are not sure what to use as a key for each request (i.e. how do we obtain a RequestContextKey from a HttpServletRequest?)

Just wondering whats the best way/ workaround at the moment?

For 1 (and using SunHttp as an example) something like this works. It's not particularly pretty as it introduces some dependencies between construction of the server and the app, but it will get you there.

https://gist.github.com/daviddenton/fdc203254813f679b17dadbb5c196f1e

The key here is that you don't need to rewrite the Jetty headers - just the Http4k headers - which will be done automatically in the case above - so you just need to "import" the RequestContextKey. There is also a way to reduce the key being passed at the expense of randomness by hardcoding the identifier instead (but the store will still need to be passed):
val key = RequestContextKey.required<MyX509Cert>(store, "cert")

For 2 - a similar thing - just compute the certificate fingerprint inside your custom jetty and then add an http4k header which is passed downstream to the filters.

HTH