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

[Christoph Läubrich]

On Tue, 10 Feb 2026 15:59:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Josiah Noel has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8368695
>>  - Merge branch 'openjdk:master' into JDK-8368695
>>  - Merge branch 'openjdk:master' into JDK-8368695
>>  - Merge branch 'master' into JDK-8368695
>>  - Merge branch 'master' into JDK-8368695
>>  - reduce diff
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8368695
>>  - Update SwitchingProtocolTest.java
>>  - Update SwitchingProtocolTest.java
>>  - Update SwitchingProtocolTest.java
>>  - ... and 11 more: https://git.openjdk.org/jdk/compare/d97ea5a8...4956aed7
>
> src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java line 183:
> 
>> 181:             uis_orig = new UpgradeInputStream(this, ris);
>> 182:         } else if (reqContentLen == -1L) {
>> 183:             uis_orig = new ChunkedInputStream(this, ris);
> 
> I would much prefer the code in the HttpHandler to opt-in for the upgrade, rather than considering that it will honour it by default. Legacy handlers that do not honour the upgrade request will get the wrong kind of input stream here, won't they?

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?

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

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