On Wed, 11 Feb 2026 11:25:52 GMT, Christoph Läubrich <[email protected]> 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
