[CONTROLLER-278] Unable to use websocket notifications from browsers Created: 07/Apr/14  Updated: 14/Nov/17  Resolved: 19/Mar/15

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

Type: Improvement
Reporter: Zoltan Lajos Kis Assignee: Zoltan Lajos Kis
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC

Attachments: File gui2.tar.gz     File sal-rest-connector.diff    
Issue Links:
Blocks
blocks CONTROLLER-287 Milestone: RESTConf improvements base... Resolved
is blocked by CONTROLLER-451 Remove cors filter from application b... Resolved

 Description   

To subscribe to websocket notifications, we need to request the location by sending a get request to "http://<host>:<port>/restconf/streams/stream/<path>", which returns the location in the "Location" header.

However, this header is unsafe and is disabled in web browsers by default. To let browsers check this field, the web server must explicitly specify this header as exposed.

This can be enabled in the configuration of the CORS filter for sal-rest-connector. See attached diff.

 Comments   
Comment by Zoltan Lajos Kis [ 07/Apr/14 ]

Attachment sal-rest-connector.diff has been added with description: configuration diff for sal-rest-connector

Comment by Tony Tkacik [ 21/Jul/14 ]

It is possible to update cors filter in controller

Comment by Jozef Gloncak [ 25/Sep/14 ]

I tested it.
In firefox I installed HTTP response browser and when I viewed response it looks like

200 OK
Server: Apache-Coyote/1.1
Cache-Control: private
Expires: Thu, 01 Jan 1970 01:00:00 CET
Location: http://localhost:8185/opendaylight-inventory:nodes/datastore=CONFIGURATION/scope=BASE
Content-Length: 0
Date: Thu, 25 Sep 2014 13:27:51 GMT

Location is there

Comment by Jozef Gloncak [ 26/Sep/14 ]

I also tested it in internet explorer 11 with add on DebugBar. After GET request on stream link I got following response

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Cache-Control: private
Expires: Thu, 01 Jan 1970 01:00:00 CET
Location: http://localhost:8185/opendaylight-inventory:nodes/datastore=CONFIGURATION/scope=BASE
Content-Length: 0
Date: Fri, 26 Sep 2014 05:41:39 GMT

So please specify more details about this problem or steps how to reproduce it.

Comment by Zoltan Lajos Kis [ 26/Sep/14 ]

I ran the attached script in Chrome when I reported the bug. (Note, it uses d3.js).

If I remember correctly, when calling getResponseHeader("Location"), Chrome rejected and reported that it is unsafe.

Comment by Zoltan Lajos Kis [ 26/Sep/14 ]

Attachment gui2.tar.gz has been added with description: JS to reproduce the bug

Comment by Jozef Gloncak [ 26/Sep/14 ]

I wasn't able to replicate it via your java script. I prepared lightweight version (see below) but neither it was possible to replicate.
function httpGet()
{
var xmlHttp = null;
xmlHttp = new XMLHttpRequest();
xmlHttp.open( "GET",
"http://localhost:8080/restconf/streams/stream/opendaylight-inventory:nodes/datastore=CONFIGURATION/scope=BASE",
true );
xmlHttp.send( null );
xmlHttp.onreadystatechange = function() {
if(this.readyState == 2)

{ alert(this.getAllResponseHeaders()); }

}
}

Therefore I prepared patch as you suggested.
https://git.opendaylight.org/gerrit/11608

Comment by Zoltan Lajos Kis [ 26/Sep/14 ]

It's quite possible this has been fixed since; there have been so many refactorings in the past six months.

I don't have the tools right now to test if this has been fixed or if the patch is necessary.

If you see the bug gone, just close the ticket. If anyone experiences it again, it'll be here for reopening...

Comment by Jozef Gloncak [ 29/Sep/14 ]

as I wrote I couldn't replicate this issue. If you have time please test it.

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