RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v5]
Daniel Fuchs
dfuchs at openjdk.org
Wed Feb 11 16:11:43 UTC 2026
On Wed, 11 Feb 2026 15:57:21 GMT, Josiah Noel <duke at openjdk.org> wrote:
>> When you send a clear http request to a server using the java.net.http client, by default the client will send an HTTP/1.1 request and upgrade headers to upgrade to HTTP/2 will be included. If the server side doesn't supports HTTP/2 it replies with HTTP/1.1. If the server supports HTTP/2 it reads the request body using HTTP/1.1, if applicable, and then sends back 101 and upgrades the connection. The rest of the exchange happens over HTTP/2.
>> 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.
>>
>> Limiting support for upgrade to GET requests in the HttpServer is not unreasonable. It means that if you want to support upgrade to HTTP/2 you will only have partial support, but since the HTTP/2 upgrade mechanism has been deprecated it's probably not a problem.
>>
>> 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.
>
>> 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?
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
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27989#discussion_r2794142354
More information about the net-dev
mailing list