[
https://issues.apache.org/jira/browse/CXF-5698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13972973#comment-13972973
]
Sergey Beryozkin commented on CXF-5698:
---------------------------------------
Hi Aki
You mean that the client starts with say "/service/root/a" and then has to
repeat "/service/root/b", etc, but instead you'd like to have
Upgrade: /service/root/a
Next: /b (/service/root/ is implied)
etc ?
Sure, it is a nice optimization but IMHO it probably needs to become optional
for the *default* binding at least,
similarly to https://issues.apache.org/jira/browse/CXF-5638.
The reason I think it may need to be optional is that the default binding
supports the pseudo-HTTP style, so in principle, we can have exactly the same
client code working with both pure HTTP and WebSocket endpoints, with only the
scheme (http vs ws) parameterized. It may not also be necessarily the easiest
path for clients who are actually aware of the complete path. Finally, I'm not
sure how well it will work with CORS added into the mix or in other security
sensitive environment (I think Colm may be liking what I'm saying here :-)),
imagine a channel hijacked, the hijacker does not even need to know the
original path....
So +1 to the optimization, but IMHO we should make it optional.
I wonder are we talking about the schema for the web socket transport so that
it is all can be customized ?
Thanks
> Use the service root path instead of the initial request path to restrict
> websocket service access
> --------------------------------------------------------------------------------------------------
>
> Key: CXF-5698
> URL: https://issues.apache.org/jira/browse/CXF-5698
> Project: CXF
> Issue Type: Improvement
> Components: Transports
> Reporter: Aki Yoshida
> Assignee: Aki Yoshida
> Fix For: 3.0.0
>
>
> Currently, the URL path used to initiate the websocket connection is used to
> allow or restrict the subsequent operations received over the websocket.
> This is not convenient as the caller must know the service root path to be
> able to invoke all the operations supported by the service. A more convenient
> approach would be to use the service root path as the filter so that the
> subsequent requests to one of its operations can be processed even if the
> initial connection request uses one of these sub resource paths.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
