Hi Josiah,
thanks for your feedback. I think your proposal is also a good option,
maybe a bit of a hidden feature in contrast to mine more explicit
declaration but it will certainly well suited!
Mine was more inspired how it works in the Servlet API but just looking
at the response code is a clever idea, I just didn't find your proposal
while searching for jdk server upgrade supper!
So whatever way seems preferred I would be fine with it and wonder whats
needed to get this feature integrated into the jdk http server?
best
Christoph
Am 23.12.25 um 16:32 schrieb Josiah Noel:
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.
