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

[Christoph Läubrich]

On Thu, 12 Feb 2026 04:58:50 GMT, Josiah Noel <duke at openjdk.org> wrote:

>>> To me it makes sense to treat it like any other request that takes an extended amount of time.
>> 
>> I'm not sure what kind of timeouts you both are talking exactly, is it read/write timeout or general timout of the overall connection exchange?
>> 
>> Because at least WebSocket can keep the connection "forever", and as we do not know the "upgraded protocol" I would say the implementer is responsible for setting up any timers to close a connection after some idle period (e.g. alive messages, maximum response times ...)
>
>> I'm not sure what kind of timeouts you both are talking exactly, is it read/write timeout or general timeout of the overall connection exchange?
> 
> [These properties govern the connection timeouts of the built in server.](https://github.com/openjdk/jdk/blob/39a1d1c801a9cbf8d21051a9af7f6279873ae260/src/jdk.httpserver/share/classes/module-info.java#L85C1-L99C74) I was going to use those to control the timeout if I thought that a request might take too long. 
> 
> Given that by default the values are -1 which means that there is no timeout, I don't really feel inclined to make a third `UPGRADED` connection state

While `maxReqTime` seems suitable here, `maxRspTime` need slight clarification here, e.g. I would say

https://github.com/openjdk/jdk/blob/39a1d1c801a9cbf8d21051a9af7f6279873ae260/src/jdk.httpserver/share/classes/module-info.java#L94

should become

> The maximum time in milliseconds allowed to receive a response headers and body **or the connection was upgraded**.

So we should assume the request being "done" once the upgrade response was send and streams are handed over canceling any timeout timers for that particular connection.

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

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