Stream: fhircast-github
Topic: docs / Issue #58 HTTP redirect handling
Github Notifications (FHIRcast) (Jan 11 2019 at 15:20):
thorstenconrad opened Issue #58
There is always a "trailing slash" problem with application servers which redirects a client to the correct endpoint. There is nothing mentioned about how the client should behave in this case.
The WebSub specs says the subscriber _should_ follow redirects.
https://www.w3.org/TR/websub/#x5-1-2-subscription-response-details
Github Notifications (FHIRcast) (Feb 05 2019 at 14:28):
isaacvetter assigned Issue #58(assigned to isaacvetter)
There is always a "trailing slash" problem with application servers which redirects a client to the correct endpoint. There is nothing mentioned about how the client should behave in this case.
The WebSub specs says the subscriber _should_ follow redirects.
https://www.w3.org/TR/websub/#x5-1-2-subscription-response-details
Github Notifications (FHIRcast) (Feb 05 2019 at 16:52):
isaacvetter commented on Issue #58
Hey @thorstenconrad ,
Apologies for the delayed, delayed response to this.
In WebSub, a subscriber following redirects particularly makes sense because the subscriber doesn't particularly care which hub it's getting updates from.
In FHIRcast, the subscriber is presenting a bearer token to the Hub. The subscriber is responsible for protecting its bearer token and it should not share it with any third-party.
Further, the subscriber was explicitly told which endpoint (
hub.topicurl) at which to initiate a subscription. Note that this is the case both in WebSub and FHIRcast. WebSub includes support for redirects, not to solve the "trailing slash" problem, but rather to federate Hubs.Why shouldn't the subscriber always expect the
hub.topicurl that it receives in the SMART app launch to always be correct (including the appropriate presence or absence of a trailing slash as required)?Isaac
Last updated: Apr 12 2022 at 19:14 UTC
