Stream: fhircast-github
Topic: fhircast-docs / Issue #303 wss returned in http header, i...
Github Notifications (FHIRcast) (Dec 10 2019 at 14:10):
isaacvetter commented on Issue #303:
Some feedback from implementers in zulip.
Github Notifications (FHIRcast) (Mar 30 2020 at 14:00):
gkustas commented on Issue #303:
Hey @isaacvetter and @wmaethner . I am having an issue implementing this. My HTTP client is trying to execute a redirect which is NOT what we want. It breaks our current implementation of our Hub. I had been commenting on Zuilp up to now: https://chat.fhir.org/#narrow/stream/179271-FHIRcast/topic/websocket.20url.2C.20in.20HTTP.20body.20or.20HTTP.20header.3F
Github Notifications (FHIRcast) (Mar 30 2020 at 14:02):
gkustas edited a comment on Issue #303:
Hey @isaacvetter and @wmaethner . I am having an issue implementing this. My HTTP client is trying to execute an automatic redirect based on the value of the Content-Location header (Windows .Net). This, of course, is NOT what we want. It breaks our current implementation of our Hub by throwing an exception because the URI does not begin with "http" or "https". I had been commenting on Zuilp up to now: https://chat.fhir.org/#narrow/stream/179271-FHIRcast/topic/websocket.20url.2C.20in.20HTTP.20body.20or.20HTTP.20header.3F
Github Notifications (FHIRcast) (Jun 16 2020 at 15:00):
isaacvetter commented on Issue #303:
@gkustas - excellent implementer-driven feedback. This limitation of .Net's HttpClient seems significant and a good reason to revert to the Hub returning the wss: url in the HTTP body, instead of the header. (It does appear that .Net Core may not have this limitation.)
I'll ping Martin / the community on our zulip thread to verify that this is okay with others as well.
Github Notifications (FHIRcast) (Jun 16 2020 at 19:40):
gkustas commented on Issue #303:
Thanks Isaac.
By the way... With our new implementation of "topic context" now being
retained by the Hub, I was thinking that the subscription response should
probably contain the current context. In this case, a simple text response
should probably be replaced with something like:{
"wss": <websocket url>,
"context": {
....
}
}Thoughts?
On Tue, Jun 16, 2020 at 11:01 AM Isaac Vetter <notifications@github.com>
wrote:@gkustas <https://github.com/gkustas> - excellent implementer-driven
feedback. This limitation of .Net's HttpClient seems significant and a good
reason to revert to the Hub returning the wss: url in the HTTP body,
instead of the header. (It does appear that .Net Core may not
<https://github.com/dotnet/runtime/issues/30965> have this limitation.)I'll ping Martin / the community on our zulip thread to verify that this
is okay with others as well.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/HL7/fhircast-docs/pull/303#issuecomment-644821123>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABODZ3XUH27MTFLEGC6FVE3RW6CLTANCNFSM4JR2FYWQ>
.--
George Kustas
Github Notifications (FHIRcast) (Sep 11 2020 at 14:22):
isaacvetter commented on Issue #303:
Ran into this during Connectathon 25, Endre Berki agrees. Need to change the spec from Content-Location to something like:
{ "hub.channel.endpoint": <websocket url> } ```` ~~~
Last updated: Apr 12 2022 at 19:14 UTC
