On Tue, 10 Feb 2026 15:24:16 GMT, Josiah Noel <[email protected]> wrote:
>> Remaking the PR since I messed up the upstream merge on the other one. See >> (https://github.com/openjdk/jdk/pull/27751) for the bulk of the previous >> discussion >> >> - adds a flag to ExchangeImpl to signal whether the current request is a GET >> Upgrade request >> - Adds a new `UpgradeInputStream`/`UpgradeOutputStream` to ensure that the >> server keeps track of when the upgraded request is closed >> - on 101 response codes, `sendResponseHeaders` will not immediately close >> the output stream >> - on 101 response codes, `sendResponseHeaders` will use an >> `UpgradeInputStream` > > 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? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27989#discussion_r2788830149
