On Thu, 12 Feb 2026 04:58:50 GMT, Josiah Noel <[email protected]> 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
