-
Notifications
You must be signed in to change notification settings - Fork 38.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document limitation around the port of localAddress in StandardWebSocketSession
#34304
Comments
StandardWebSocketClient
creates WebSocketSession
with local address with incorrect port
Thanks for the report. You're correct, but |
@rstoyanchev Do you think it would be productive to start a conversation in the Jakarta Websocket API project about adding a |
I think it is a good idea. I found jakartaee/websocket#255 for remote address that mentions local address, but it was created a while ago. Maybe it can be revived with more comments and votes. Perhaps the title can be updated too to reflect a request for both local and remote address. |
StandardWebSocketClient
creates WebSocketSession
with local address with incorrect portStandardWebSocketSession
@rstoyanchev I will open a discussion in https://github.com/jakartaee/websocket referencing this issue sometime later. But don't you think that it's a better solution to make |
The method allows for returning null. We could probably do that rather than throw an exception. I've created #34331. |
During migration from Spring 6.0 and replacing
JettyWebSocketClient
withStandardWebSocketClient
we noticed thatStandardWebSocketSession
incorrectly returns a remote port instead of a local port fromWebSocketSession#getLocalAddress()
for the client WS session. Old removedJettyWebSocketSession
was implementing this method correctly. It was returning the port of the local socket of the underlying TCP connection.This problem comes from the following implementation in
StandardWebsocketClient
which is obviously erroneous:Client WS Session shouldn't use the same port value for both the local and remote addresses.
There was a previous report about this bug and regression that was incorrectly closed for being a question: #22395
Workaround
To work around this bug, instead of
users should do
when are using Jakarta WS implementation.
The text was updated successfully, but these errors were encountered: