On Tue, 14 Oct 2025 13:04:07 GMT, Michael McMahon <[email protected]> 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
