Stream: FHIRcast
Topic: websocket url, in HTTP body or HTTP header?
Isaac Vetter (Nov 26 2019 at 16:09):
When a FHIRcast client requests and is granted a new websocket subscription, the Hub returns a wss:// url which the client subsequently connects to and event notifications are sent over.
Isaac Vetter (Nov 26 2019 at 16:10):
Both in our informal wiki writeup and in our draft websocket spec, the Hub returns this wss url in the body of the HTTP response.
Isaac Vetter (Nov 26 2019 at 16:10):
On a recent II call, @Bill Wallace recommended that this wss url is returned to the subscribing client, not in the HTTP body, but rather in the Content-Location HTTP header. Bill made the point that this would make FHIRcast a bit more consistent with DICOM's use of websockets (which do the same thing). Re-using an existing HTTP header also feels classy and a bit more RESTful. My understanding of Content-Location is that this would be an appropriate use of the header. I've written up a PR to make this change to our draft websockets spec.
Isaac Vetter (Nov 26 2019 at 16:10):
Does anyone have feedback or concern about this change? Especially if you've already developed support for websockets? (@George Kustas , @Martin Bellehumeur , @Leo Bergnéhr , @Will Maethner , @Wouter Devriendt )
George Kustas (Nov 26 2019 at 17:33):
Sounds OK to me, but there are several implementations working now that will need to change. I think that is OK, since we’re all in “RSNA demo code” now. We’ll have to make a video and share it. Lots happening!
Martin Bellehumeur (Visage Imaging) (Dec 05 2019 at 14:21):
Does anyone have feedback or concern about this change? Especially if you've already developed support for websockets? (George Kustas , Martin Bellehumeur , Leo Bergnéhr , Will Maethner , Wouter Devriendt )
For us it will require a change that could take some time. I have filed the request.
Martin Bellehumeur (Visage Imaging) (Dec 05 2019 at 14:23):
Congrats to @George Kustas for the launch of Powercast at RSNA. I think the first FHIRcast hub on the market. You’re a pioneer! :tada:
George Kustas (Dec 05 2019 at 16:39):
Team effort from @Martin Bellehumeur , @Niklas Svenzén , Barco, Primordial and more who really pulled it all together to show FhirCast do it's thing. Context sharing off course, but also two-way clinical findings updates (including measurements).
George Kustas (Mar 16 2020 at 19:57):
I am finally implementing this in our hub and running into a problem. It appears that only "http" and "https" are valid in the content-location. The client is throwing the exception. Any suggestions @Martin Bellehumeur , @Bill Wallace , @Isaac Vetter
George Kustas (Mar 16 2020 at 20:06):
after reading this, I'm not so sure that we should be using content-location for the websocket connection endpoint: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Location
Vassil Peytchev (Mar 16 2020 at 20:41):
In general, there doesn't seem to be a restriction on the URI protocol that can be used in content-location. Whether that header is the appropriate place for the websocket URL, I don't know. One thing to consider might be the difference in HTTP 1.1 and HTTP/2 in the way the websocket connection is bootstrapped...
George Kustas (Mar 16 2020 at 23:09):
The fact that using it caused an exception in the Microsoft .Net implemented library worries me. I don't think we're using it as intended. Perhaps this would be a better alternative: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Accept. But I would rather keep it in the body for now.
Martin Bellehumeur (Visage Imaging) (Mar 17 2020 at 08:08):
I tested against sandbox.js and my PACS client gets the content-location header. Which hub have you added to? I tried connect and connect2 but did not see the header set.
George Kustas (Mar 17 2020 at 13:18):
INtertesting... What library is your client using? IS that javascript?
Isaac Vetter (Jun 16 2020 at 15:13):
Hey Guys - sorry for the ridiculously late response. @George Kustas, this is excellent feedback. I think that the last thing we want to do is have the base spec be incompatible with a framework as common as .Net's HttpClient.
@Martin Bellehumeur - any concern with switching back to the response body?
Background
In PR#303, we updated the Subscription Response from the Hub to return a websocket wss: url via the Content-Location header; however, this causes some issues with web communication patterns in .NET Framework. Basically, when using the Framework HttpClient class and SendAsync, if Content-Location is set on a response, the HttpClient will reset the URI of the request to the value of the Content-Location header (like a redirect). This causes issues when our content location is a "wss://" prefixed URI because the HttpClient only accepts "http://" or "https://" protocols, obviously. There doesn't appear to be a reasonable way to work around this issue with HttpClient, even using a configurable HttpClientHandler.
Martin Bellehumeur (Visage Imaging) (Jun 19 2020 at 09:30):
Hi Isaac, I have no concerns with switching back to the response body.
Isaac Vetter (Sep 11 2020 at 14:31):
PR here: https://github.com/HL7/fhircast-docs/pull/333
cc/ @Bas van den Heuvel , @George Kustas , @Endre Berki
Last updated: Apr 12 2022 at 19:14 UTC
