Stream: implementers
Topic: http & https Resource references
Angus Millar (Jul 04 2017 at 13:19):
I just added https to my FHIR server endpoint and it got me thinking about the references between resources. If I have an Observation resource that references a Patient resource using the subject property, and I use an absolute reference, e.g. https://SomeServer/fhir/Patient/100, when searching for Observation resources with a particular subject URI should a server return matches for both http & https? So that would be, should this search:
https://SomeServer/fhir/Observation?subject=https://SomeServer/fhir/Patient/100
return Observation resources with a subject of http://SomeServer/fhir/Patient/100 as well as resource with https://SomeServer/fhir/Patient/100
Grahame Grieve (Jul 05 2017 at 05:43):
difficult question.
Grahame Grieve (Jul 05 2017 at 05:44):
we've said that those references can't reference different resources, so that would argue that the you should resolve them
Brian Postlethwaite (Jul 05 2017 at 05:44):
My server knows what it is, and while internally referencing removes the absoluteness off there.
Brian Postlethwaite (Jul 05 2017 at 05:44):
(as in knows its own base URLs, so can strip the prefixes to make them relative)
Angus Millar (Jul 05 2017 at 13:33):
the FHIR spec says this for URI search "The uri parameter refers to a URI (RFC 3986 ) element. Matches are precise (e.g. case, accent, and escape) sensitive, and the entire URI must match."
Angus Millar (Jul 05 2017 at 13:39):
Which then means that this search https://SomeServer/fhir/Observation?subject=https://SomeServer/fhir/Patient/100 would only return the subjects with a 'https' and yet this search https://SomeServer/fhir/Observation?subject=Patient/100would return both https and 'http'. I think that is reasonable although a little unintuitive. Doing this meets all the rules I can find in the spec.
John Moehrke (Jul 05 2017 at 13:50):
see the http(s) text http://build.fhir.org/http.html#general
John Moehrke (Jul 05 2017 at 13:51):
generally you are asking more of a policy question, than a specification question. Meaning Policy will decide to never publish anything under http; but it might allow queries to ask about http and interpret those queries as if they were https. Hopefully Policy will not ever allow non secure things.
Angus Millar (Jul 05 2017 at 14:46):
Thanks, John that is a good reference on the topic. It somewhat contradicts the reference I posted above from the URI search. On policy, it's difficult to control content created outside of one's policy boundary. Sure I can have a policy that my server only operates on https but it's harder to mandate that the content I consume never references content outside of my boundary on http. I may have a resource with a reference to an Organization resource in another FHIR server completely outside of my policy controls. I think I'm now leaning towards ignoring the schema on all base url's for search, just match from :// forward, except for urn:oid and urn:oid.
Lloyd McKenzie (Jul 05 2017 at 16:22):
@Angus Millar Can you submit a change request for us to clarify the language?
Cooper Thompson (Jul 05 2017 at 21:14):
Another related practical problem that we've run into is that the "service base URL" that the FHIR server knows itself as may be different than what the FHIR client knows the server as (not just http vs. https, but also the host and base-path). For example when reverse proxies and re-write rules are in place in a DMZ that separates a protected FHIR server from a client on the public internet. Our challenge has been that in order to make references resolvable by the FHIR client, references need to be relative to the reverse proxy "service base URL", which may not be the same as the FHIR server "service base URL".
http vs. https seems like a subset of this problem that can be caused in real life by TLS termination proxies, for example.
Not entirely sure this is something for the FHIR standard to tackle, but it's definitely a pain point for us, and related to the http vs. https thing, so I figured I'd mention it.
Angus Millar (Jul 05 2017 at 22:20):
Ouch, thanks for that Cooper, certainly another dynamic to consider. At first glance it looks like the server need to inspect the request headers for: HTTP_X_ORIGINAL_URL – this server variable contains the original URL in decoded format; and
UNENCODED_URL – this server variable contains the original URL exactly as it was requested by a Web client, with all original encoding preserved.
Last updated: Apr 12 2022 at 19:14 UTC
