On Thu, 12 Feb 2026 04:43:20 GMT, Christoph Läubrich <[email protected]> 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
