Should jakarta.websocket.ClientEndPoint.Configurator.afterResponse(HandshakeResponse hr) be called even on failed upgrade?

[joakime]

Currently, in the Jetty implementation, the jakarta.websocket.ClientEndPoint.Configurator.afterResponse(HandshakeResponse hr) is only called on successful handshake, not on failed handshake.

I'm curious what other implementations do, and if this API should be called as well on bad / failed handshakes as well?

With the evolving nature of various firewalls, load balancers, etc (such as those that mitigating DDoS traffic) sometimes the response arrives and the client application needs to have access to these response headers to know what to do. (eg: challenge the user, authenticate, slow down, etc)

Currently, with the API as it stands these failed attempts to connect are hidden in the black box of the WebSocket Client behaviors.
I just want to see us expose this information in a useful way for developers.

[markt-asf]

Looking at Tomcat's implementation, I'm not sure how this would work.

Tomcat handles redirects and authentication requests transparently. I think we'd need a new API (or APIs) if we wanted the client to be able to get involved in that process.

In Tomcat the client either sees a successful connection or an exception.