Stream: implementers
Topic: HTTP OPTIONS and CORS
Rick Riemer (Apr 13 2016 at 15:25):
While testing our PDQm consumer at the IHE Connectathon, we found that many servers weren't handling our requests, due to our (browser based) client sending HTTP OPTIONS requests. This is caused by the browsers implementing the Cross Origin Request (CORS) protocol.
The CORS protocol describes that non-trivial requests (e.g. GET requests with Authorization headers) should be preceded by a so called CORS preflight request, which is an HTTP OPTIONS call. Servers don't seem to be expecting this.
In the interest of interoperability, I'm interested to seeing who should be fixing this. The clients not sending the HTTP CORS requests, or the servers correctly handling them. In my opinion FHIR should make it easy to create clients, so the browser behavior will be encountered more often and the servers should just handle this (there are CORS filter libraries out there for Java server implementers).
What do the implementers here think?
Jenni Syed (Apr 13 2016 at 17:18):
Hi Rick - do you know which servers weren't handling this? Is this just via an unauthenticated flow or authenticated? I know the Conformance statement allows servers to specify CORS support: http://hl7.org/fhir/dstu2/conformance-definitions.html#Conformance.rest.security.cors
David Hay (Apr 13 2016 at 17:19):
Sorry - not quite clear - was the issue that clients didn't send the pre-flight, or that they did and the servers didn't process correctly...
Rick Riemer (Apr 13 2016 at 18:12):
It was about servers not handling the preflight CORS request. It was caused by our clients sending Authentication headers, which made the requests non-trivial and thus triggering the browser to try a CORS preflight first. When we removed the Authentication, there wasn't any CORS.
I wasn't aware about the conformance possibility, but I don't think it's really a Conformance choice for servers. Servers need to support it at least in combination with Authentication, as the browser clients will automatically send CORS preflight if required. It can only be prevented by removing all Authentication and alike headers.
My suggestion is that there's some clarification towards CORS needing to be supported on servers. WDYT?
Peter Scholz (Apr 13 2016 at 18:35):
It is a bit tricky, as HTTP OPTIONS request is treated as a request for a conformance statement in FHIR,
so sending pre-flight requests will produce may prodoce some overhead on the server side,
I wonder how many systems will use browser based clients and thus need CORS support.
But on the other hand it ist not too complicated to add CORS handling, so at least it should be possible to add it on the server side.
Jenni Syed (Apr 13 2016 at 18:45):
From what I've seen, generally if you support the SMART standard on top of FHIR, you likely support CORS (as a server). But if a server chooses not to trust browser-based cross origin, then that would be up to their security stance.
Jenni Syed (Apr 13 2016 at 18:45):
As to clients - usually as a javascript client you don't have a choice - the browser handles cors for you. It doesn't apply to non-browser based calls
Jenni Syed (Apr 13 2016 at 18:46):
The Options request isn't that hard to filter out in the server (to differentiate from the Conformance request) because the Origin header is on there
Grahame Grieve (Apr 13 2016 at 20:22):
Rick - CORS is proving hard for many servers. Especially the intersection between CORS and authentication, and the registration of a client. Can you be specific about which servers are a problem?
Rick Riemer (Apr 14 2016 at 09:53):
There were various servers here at the IHE Connectathon. Some have put in temporary solutions for working through the Connectathon (Indra, Systelab), some completely fixed it (OSM, Visus), and some mentioned that they might fix it somewhere down the road (ICW, Lexmark).
David Hay (Apr 15 2016 at 18:49):
from my perspective (developing the clinFHIR resource builder for the clinician challenge) I'm doing everything in the browser, so CORS has become essential for me... I didn't realize the issue around the preflight request which might explain some puzzling errors I've had! Would definitely appreciate clarification around that - maybe OPTIONS is no longer a good choice for the conformance resource?
David Hay (Apr 15 2016 at 18:50):
(ah - just saw Jenni's comment)...
Michael Lawley (Apr 18 2016 at 15:10):
We ran into an issue a while bacl (I think it was with HAPI) where OPTIONS on [base]/** always gave back the metadata rather than just on [base]
Peter Bernhardt (Apr 18 2016 at 16:32):
peter scholz, you wrote "It is a bit tricky, as HTTP OPTIONS request is treated as a request for a conformance statement in FHIR..." HTTP OPTIONS is really about the communication options available for a given server (e.g., does it support GET, UPDATE, etc.). The FHIR Conformance statement is more about what the FHIR services available at a particular FHIR server. FWIW, I've tested a number of FHIR servers from my browser-based client and all have implemented CORS correctly (if they don't, I let them know about it ;)
Peter Scholz (Apr 19 2016 at 03:30):
We did implement handling of CORS too. But that does mit change my statement as the FHIR spec says that you have to respond to a HTTP OPTIONS by sending a conformance resource
Grahame Grieve (Apr 19 2016 at 03:50):
I don't think it does actually say that. But perhaps we could be specific about CORS
Michael Lawley (Apr 19 2016 at 05:07):
AT the least I think you should be clear that it is only OPTIONS on the [base] URL that should trigger the conformance resource (although why this is needed when [base]/metadata exists I am not sure)
Peter Bernhardt (Apr 19 2016 at 15:28):
I can't find that in the FHIR spec. And if it is, it should be changed.
Peter Scholz (Apr 19 2016 at 15:59):
Section 2.1.025 reads
GET [base]/metadata or OPTIONS [base] triggers the sending of the Conformance Resource
Peter Scholz (Apr 19 2016 at 16:00):
Sorry should be 2.1.0.15
Peter Bernhardt (Apr 19 2016 at 16:17):
thanks for the link, Peter. I've just added a change request here: http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=9841
Peter Scholz (Apr 19 2016 at 18:35):
Perfect
Patrick Werner (Sep 15 2016 at 15:23):
is there any update on this? we try to access a HAPI 2.0 server build from the hapi jpa example. CORS is supported by the JPA example server like it is described here: http://hapifhir.io/doc_cors.html
However we are still getting preflight errors:
fhir-client.min.js:5 OPTIONS https://fhir.iap.hs-heilbronn.de/baseDstu2/Specimen send @ fhir-client.min.js:5ajax @ fhir-client.min.js:5http @ fhir-
orders.html:1 XMLHttpRequest cannot load https://fhir.iap.hs-heilbronn.de/baseDstu2/Specimen. Response for preflight has invalid HTTP status code 403
James Agnew (Oct 07 2016 at 02:41):
HTTP 403 sounds to me like the issue isn't CORS, but rather authentication.. That server seems to be down right now, but does it allow anonymous access?
Last updated: Apr 12 2022 at 19:14 UTC
