FHIR Chat · Relative paths in Location header? · implementers

Stream: implementers

Topic: Relative paths in Location header?


view this post on Zulip Morten Ernebjerg (Aug 27 2018 at 10:56):

I was wondering whether it is allowed to return just the relative path in the Location HTTP header when creating new resource, or whether it has to be the full absolute URL. The general STU 3 documentation of the FHIR RESTful API operation create says:

The server returns a 201 Created HTTP status code, and SHALL also return a Location header which contains the new Logical Id and Version Id of the created resource version:
Location: [base]/[type]/[id]/_history/[vid]

Here, it was not quite clear to me whether the specific URL pattern (specifying an absolute URL) is normative or just an illustrative example that does not exclude relative URLs. The general HTTP/1.1 specs allows both absolute and relative paths in the Location header (see this page).

view this post on Zulip Lloyd McKenzie (Aug 27 2018 at 14:06):

@Grahame Grieve ?

view this post on Zulip Jaime Olivares (Aug 27 2018 at 16:05):

I have the same question.

view this post on Zulip Grahame Grieve (Aug 27 2018 at 19:22):

we don't actually say, so for clients, it could be either. My server returns an absolute URL, which starts with the client's host header - .e.g. an absolute URL

view this post on Zulip Morten Ernebjerg (Aug 28 2018 at 09:33):

Thanks! - just to make sure I understand, it is then also OK for servers to opt for using relative paths?

view this post on Zulip Lloyd McKenzie (Aug 28 2018 at 15:08):

That's what I'm hearing from the discussion. Feel free to submit a change request for us to make that clarification explicit in the spec.

view this post on Zulip Elliot Silver (Aug 28 2018 at 17:28):

Is including the full URL a better approach if using forwarding/proxy servers? Or are they going to need to rewrite anyhow?

view this post on Zulip John Moehrke (Aug 28 2018 at 17:44):

very interrelated with the digital signatures problem. As it stands today we place alot of trust in the FHIR Server. http://build.fhir.org/signatures.html

view this post on Zulip Morten Ernebjerg (Aug 29 2018 at 12:02):

@Lloyd McKenzie Added a GForge item for clarification, #17746, also mentioning the topic of using FHIR with federated/proxied servers as a context where this could be important (cf. comment from @Elliot Silver)


Last updated: Apr 12 2022 at 19:14 UTC