[proposal] Add Upgrade Support to JDKs HttpServer
Christoph Läubrich
mail at laeubi-soft.de
Wed Dec 24 06:00:56 UTC 2025
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.
More information about the net-dev
mailing list