provides draft of the enhanced websocket handling #691
Conversation
Signed-off-by: Oleh Dokuka <[email protected]>
rsocket-examples/src/main/java/io/rsocket/examples/transport/ws/WebSocketHeadersSample.java
Outdated
Show resolved
Hide resolved
Signed-off-by: Oleh Dokuka <[email protected]>
...les/src/main/java/io/rsocket/examples/transport/ws/WebSocketRouteTransportHeadersSample.java
Outdated
Show resolved
Hide resolved
Signed-off-by: Oleh Dokuka <[email protected]>
Signed-off-by: Oleh Dokuka <[email protected]>
...transport-netty/src/main/java/io/rsocket/transport/netty/server/WebsocketRouteTransport.java
Outdated
Show resolved
Hide resolved
…ty/server/WebsocketRouteTransport.java Co-Authored-By: Yuri Schimke <[email protected]>
| return isError; | ||
| } | ||
|
|
||
| if (headersPredicate != null) { |
There was a problem hiding this comment.
Couldn't this be simplified by having a default headers predicate that always returns true?
|
|
||
| public static class Builder { | ||
|
|
||
| private Predicate<HttpHeaders> headersPredicate; |
There was a problem hiding this comment.
Why split headersPredicate and webSocketCloseStatusSupplier? Seems like this could be combined into a single function call instead?
There was a problem hiding this comment.
Do you think that returning null in case everything is fine is a better approach? I was thinking about API which allows a user to filter incoming connection out and in case it is rejected to provide a specific close status. One of the options is to use SynchronousSink (as it is in Reactor) but it seems way complex as of normal developer standpoint (e.g. calling error or success)
There was a problem hiding this comment.
In this case splitting it means possibly evaluating the rules twice, so probably. Or use optional?
|
close in favor of #835 |
This PR provides some enhancement in WebSocket client/server API which allows manipulating connection handling + receiving a human-readable reason for closed WebSocket.
For more info see forum discussion -> https://community.netifi.com/t/accessing-http-connection-headers-and-path/180
Also related (rsocket/rsocket-js#42)
Signed-off-by: Oleh Dokuka [email protected]