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

[Christoph Läubrich]

On Wed, 11 Feb 2026 16:08:55 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> At this time I'm probably more concerned about the implication of supporting upgrade in this way, and the impact on connection life cycle, and management of the server connection pool.
>> 
>> Could you expand on these implications? I'm not sure I completely follow.
>
> From the top of my head:
> 
> - How is the connection eventually closed?
> - When the exchange is closed, is the connection returned to the pool, or should it be closed? If it should be closed we do not want to rely on the peer closing it.
> - If the peer closes the connection, will it linger in any of the map/list in which the server keeps track of opened connection?
> - What should happen if the server is stopped while the connection is still active?
> - Should a still active upgraded connection be considered as using up one space in the connection pool?
> - What if there is a request timeout on the server side? Does it apply to upgraded connections? Are they still in the REQUEST state?
> 
> Do we have a test for each of these cases?
> FWIW - we are still discovering issues with HttpServer::stop - see https://bugs.openjdk.org/browse/JDK-8377302

> Since the body of the request (if present) is sent using HTTP/1.1, it might use Transfer-Encoding: chunked; Only after the body has been read can the connection be upgraded to HTTP/2. 
> But if the server side doesn't support the upgrade it just ignore those headers, reads the body as normal, sends 200, and sends the response body as usual.

I don't see how this is limited here what happens do the body (except currently it is only seems limited by GET) is preventing such case and how it relates to legacy handlers.

To maybe make it more clear the JDK HttpServer *can* be used to process the **Upgrade request** right now without a problem, the issue arise that when sending the http response headers, the connection is closed / returned to the server so one can't further use the streams what is **mandatory for a connection Upgrade**.

> How is the connection eventually closed?

This depends on the protocol of course, e.g. in case of WebSocket each side can initiate a connection shutdown and one can do it like with regular raw sockets that closing any of the streams will close the connection.

> When the exchange is closed, is the connection returned to the pool, or should it be closed?

As far as I understand the HTTP spec an upgrade connection can not be reused in the sense as it comes to persistent Http1 connections.

> What should happen if the server is stopped while the connection is still active?

I think its rather obvious that then we need to close all open sockets (as what happens with Http1 currently maybe after a certain delay).

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

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