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

[Josiah Noel]

On Tue, 14 Oct 2025 13:04:07 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> it would have to be documented and specified, so that other people could use it.

For me, it was already implied that 101 status could be sent, because the documentation for `sendResponseHeaders` did not even hint that it treats informational responses like 204/304 status codes and closes the streams. No matter what happens, 
I agree that we should update the documentation.

> probably through a new method on HttpExchange

For http2 I'm in agreement for a new method, as supporting that kind of upgrade is has far more complexity and requires consuming the body before upgrading.

For WebSocket though, such a thing can be accomplished cleanly through the current API. Indeed, in some other implementations of `jdk.httpserver` I'm able to upgrade to websocket with the same API because 101 status was not treated like a 204, and the streams were not closed immediately.

> As a minimum, the feature would have to be "opt in" by the handler,

Requiring a manual call of `sendResponseHeaders(101, 0)` and the requirement to custom implement the entire protocol appears pretty opt in to me. 

> we have to consider the impact on the rest of the API, such as what happens when HttpServer.stop is called.

Testing locally, calling stop appears to work the same as an extended GET request. What kind of test assertions would you like to see?

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

PR Comment: https://git.openjdk.org/jdk/pull/27751#issuecomment-3401900691