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

[Josiah Noel]

On Thu, 12 Feb 2026 04:43:20 GMT, Christoph Läubrich <duke at openjdk.org> wrote:

>>> The question then is - should they? I mean do the current connection states REQUEST / RESPONSE
>> still make sense for an upgraded connection? Do we need a third state - like UPGRADED, and a third bucket to put upgraded connections?
>> 
>> I was just going to up the timeouts on my own application personally. To me it makes sense to treat it like any other request that takes an extended amount of time.
>
>> 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 the 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

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

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