Stream: bulk data
Topic: Content-Location Header
Grahame Grieve (Sep 29 2018 at 14:44):
Currently, in the documentation, we do not say whether the content-location returned from the initial request is absolute or relative. Nor do we say anything about whether it can be a reference to another server
Grahame Grieve (Sep 29 2018 at 14:44):
that just caught me out
Grahame Grieve (Sep 29 2018 at 14:45):
I propose that we clarify this explicitly - whether the Content-Location can be absolute or relative. There's 3 options:
Grahame Grieve (Sep 29 2018 at 14:45):
absolute: the content-location header must contain an absolute URL
Grahame Grieve (Sep 29 2018 at 14:45):
relative: the content location header must contain a relative URL
Grahame Grieve (Sep 29 2018 at 14:46):
either: the content location header can contain either, and we document this explicitly
Grahame Grieve (Sep 29 2018 at 14:46):
vote for your preference with a thumbs up
Grahame Grieve (Sep 29 2018 at 14:47):
Also, unless we decide it must be relative, we should add a rule that if the content-location refers to another server, the access tokens must work on that target server (no new authentication)
Josh Mandel (Sep 29 2018 at 14:59):
(https://github.com/smart-on-fhir/fhir-bulk-data-docs/pull/75/files?short_path=1542050#diff-1542050bd54a14a0d9937b4f7db31db0 has a preview of what this change look like if we go the "absolute" route)
Josh Mandel (Sep 29 2018 at 15:16):
Merged!
John Moehrke (Sep 29 2018 at 18:57):
Also, unless we decide it must be relative, we should add a rule that if the content-location refers to another server, the access tokens must work on that target server (no new authentication)
That seems like an unlikely to be true situation except in very constrained cases. Are we constraining this for short-term connectathon success, or long-term architecture?
Grahame Grieve (Sep 29 2018 at 19:52):
long term.
Grahame Grieve (Sep 29 2018 at 19:53):
why do you think that's unlikely?
John Moehrke (Sep 29 2018 at 20:18):
because a security token is often specific to the request context, which is going to be different when one requests information from another service. Epecially when two services are in two different organizations.
Grahame Grieve (Sep 29 2018 at 20:28):
well, that's the point; what we want is for the redirect from the async request to have a contract that it will not require different tokens
Last updated: Apr 12 2022 at 19:14 UTC
