RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v5]

[Josiah Noel]

On Wed, 11 Feb 2026 11:25:52 GMT, Christoph Läubrich <duke at openjdk.org> wrote:

>>> I must confess I don't know what "legacy" mean because currently the upgrade simply always fails so how could a handler make any use of this?
>> 
>> I know it's been deprecated, but consider the upgrade to HTTP/2 for instance. If the peer doesn't support HTTP/2 it can just ignore the upgrade headers and continue with HTTP/1.1. Upgrade is a rather general mechanism, and for instance, AFAIK, you can even upgrade to HTTP/2 with POST, although it brings its own lot of issues (the request body has to be read using HTTP/1.1 and then only the connection can be upgraded).
>
>> I know it's been deprecated, but consider the upgrade to HTTP/2 for instance. If the peer doesn't support HTTP/2 it can just ignore the upgrade headers and continue with HTTP/1.1. 
> 
> As Upgrade is not and never was supported here, a ~client~ handler can't upgrade anyways and therefore can't send `101 Switching Protocols` (or at least if trying will fail as connection is closed for them).
> 
> So if you think there is a problem it would be bet to show a minimal reproducer that can then be added as a test-case to proof it is still working.

> you can even upgrade to HTTP/2 with POST,

Yeah that's something I avoided by restricting to GET methods. Can we consider this thread resolved then?

> As Upgrade is not and never was supported here, a client handler can't upgrade anyways

He is thinking of scenarios where the body might still try to be read even though the connection is not upgraded, it's about backwards compatibility.

> So if you think there is a problem it would be bet to show a minimal reproducer that can then be added as a test-case to proof it is still working.

As the ones trying to propose the feature it is on us to give an airtight case for why it has no problems.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27989#discussion_r2793376285