Do you really need 2 different handler interfaces?

There is a long history of HTTP frameworks that have a uniform interface for both client and server, for a project that in embracing chaining and proxy of HTTP seems a bit crazy to force people to convert between incoming-handler and outgoing-handler when outgoing-handler could very easily do both.

Some examples of frameworks that have a uniform interface for both client and server

• fetch / Service Workers (nearly) - see Cloudflare workers, Bun serve for more uniform examples.
• Restlet Java
• UtterlyIdle Java
• HTTP4K Kotlin
• Finagle Scala
• Amp PHP

I'm sure there are a lot more.

Anyway why does this matter?
It means for creating proxy you just pass the request directly from the server handler to the client handler and then return the response. For middleway it's just another handler, for filters just another handler, for testing in memory just use the server handler without the TCP wrapper.

Anyway I hope you will consider it, it would be shame for probably the most portable and highly important interface in HTTP to ignore one of the most powerful abstractions the decorator pattern and instead double the amount of work for everyone to convert back and forward between the two interfaces.

The issue names the incoming-handler and outgoing-handler interfaces but no files, tests, or entry points. Start by locating those interface definitions and their conversion sites, then determine whether a unified handler can cover both client and server use cases and what tests would establish compatibility.