[CONTROLLER-1147] websocket does not implement the ws:// protocol defined in the URI scheme in rfc6455 Created: 10/Feb/15  Updated: 25/Jul/23  Resolved: 05/May/15

Status: Resolved
Project: controller
Component/s: adsal
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: RichardHill Assignee: Jan Hajnar
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

External issue ID: 2699

 Description   

Tested Helium SU2

Steps
I followed https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Restconf:Change_event_notification_subscription

I subscribed to

"http://<host>:8181/opendaylight-inventory:nodes/datastore=CONFIGURATION/scope=BASE"

In the wiki I couldn't initially find the URI to point the websocket client at because I expected a WS:// protocol as described in section 3 http://tools.ietf.org/html/rfc6455
*****************
3. WebSocket URIs

This specification defines two URI schemes, using the ABNF syntax
defined in RFC 5234 [RFC5234], and terminology and ABNF productions
defined by the URI specification RFC 3986 [RFC3986].

ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]
wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ]

host = <host, defined in [RFC3986], Section 3.2.2>
port = <port, defined in [RFC3986], Section 3.2.3>
path = <path-abempty, defined in [RFC3986], Section 3.3>
query = <query, defined in [RFC3986], Section 3.4>

*************

To investigate the effect of using http:// I used the python websocket client
autobahn which refused the http:// URI as a wrong protocol and firefox which failed to connect.

 Comments   
Comment by RichardHill [ 10/Feb/15 ]

Further reading of the RFC (Section 4) indicates the failure to connect is expected because during an opening handshake "A client will need to
supply a /host/, /port/, /resource name/, and a /secure/ flag, which
are the components of a WebSocket URI as discussed in Section 3"

Comment by Jan Hajnar [ 02/Mar/15 ]

Hi,

I tested simple websocket client written in javascript and also chrome extension Simple Websocket Client and when you substitute "http" protocol in path for "ws" I was able to successfuly connect to server and receive notifications.

here is simple patch for helium that returns location header parameter with "ws" protocol.
https://git.opendaylight.org/gerrit/#/c/15925/

You should be able to listen to notifications on that path via standard websocket clients.

For Lithium further modification is probably needed.

Comment by Carol Sanders [ 05/May/15 ]

This bug is part of the project to Move all ADSAL associated component bugs to ADSAL.

Generated at Wed Feb 07 19:54:48 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.