This is also one of my dearest wishes, I also have a PR open to support upgrades <https://github.com/openjdk/jdk/pull/27989>, but I'll take anything at this point.
I didn't go with a new api in my design because I wanted to be backwards compatible with the other implementations of jdk.httpserver that support upgrades via sendResponseHeaders, but if that's what it takes then. Thread Management: Should upgrade handlers run on the existing server > thread pool or require explicit executor configuration? I would say it should use the existing one, what would be the real benefit of a separate executor? Stream Lifecycle: Should the server close streams after handler completion, > or should handlers have full responsibility? Security Considerations: Should there be built-in limits or hooks for > upgrade validation? Personally, I think once its decided to upgrade, all the details should be implemented by the user. Should HttpUpgradeHandler remain in jdk.httpserver or move to a separate > API module? I find myself confused by this, if the point is to add missing functionality to the jdk.httpserver, why put it anywhere else? -- Cheers, Josiah.
