Stream: inferno
Topic: Retrieve well-known
Jenni Syed (Feb 02 2021 at 18:05):
Sanity check before I log an issue: I believe when requesting the SMART well-known endpoint, we would expect an application to populate the expected Accept header appropriately?
Jenni Syed (Feb 02 2021 at 18:05):
We're seeing inferno program edition fail the well known call b/c it's receiving a 406 from us, but it doesn't look like any Accept header is sent in
Yunwei Wang (Feb 02 2021 at 18:21):
@Jenni Syed , We do realized that header issue. Inferno had a ticket logged if Inferno should send Accept header. We decide not to send since SMART App Launch IG does not say such Accept header is required.
http://build.fhir.org/ig/HL7/smart-app-launch/conformance.html#using-well-known
Jenni Syed (Feb 02 2021 at 18:28):
well-known is a broader standard than just SMART though
Yunwei Wang (Feb 02 2021 at 18:30):
It is not mentioned in here either: https://tools.ietf.org/id/draft-ietf-oauth-discovery-08.html#ASConfigurationRequest
Jenni Syed (Feb 02 2021 at 18:30):
And since it's off the FHIR URL, FHIR does have an opinion on Accept
Yunwei Wang (Feb 02 2021 at 18:31):
FHIR has option on FHIR resource. well-know does not return a FHIR resource.
Jenni Syed (Feb 02 2021 at 18:32):
Also, the spec doesn't call out that Content-Type is required either :) This seems really odd to not assume someone is going to follow good http practice and send in an Accept
Yunwei Wang (Feb 02 2021 at 18:32):
It does say "A JSON document must be returned using the application/json mime type."
Jenni Syed (Feb 02 2021 at 18:34):
kk - I'll log something against our server...
Yunwei Wang (Feb 02 2021 at 18:34):
One discuss we had is that if client send "Accept: application/xml" to well-know, should the server reject such request. According to SMART, it should not since it "always" return application/json.
Jenni Syed (Feb 02 2021 at 18:34):
feels odd to fail an unspecified requirement :)
Jenni Syed (Feb 02 2021 at 18:36):
where was that discussion so I can reference it?
Yunwei Wang (Feb 02 2021 at 18:41):
It is part of our internal ticket. You can reference this discussion as a summary.
Jenni Syed (Feb 02 2021 at 18:47):
was there anything logged to SMART to correct the spec/clarify?
Yunwei Wang (Feb 02 2021 at 18:49):
If SMART can clarify that, it would be better. But we didn't create a ticket there.
Jenni Syed (Feb 02 2021 at 18:56):
Santosh Pai (Feb 02 2021 at 22:41):
Hi - new to the SMAR on FHIR paradigm. Our need is to have a place in the flow to have a intermediate page shown to the user where they can select what resource that they want the app to be authorized to use ( Claims, Medications etc). Has anybody have experience with this flow ?
Yunwei Wang (Feb 03 2021 at 01:26):
@Santosh Pai please open a new topic in #implementers stream.
Robert Scanlon (Feb 03 2021 at 14:36):
Thanks for working to get clarification on this @Jenni Syed . We debated this internally on our team a few months back, which boiled down to 'http best practices is to send an Accept header so we should just do that' on one side and 'the specs do not require clients to send the Accept header, and even the examples leaves it out' on the other side. Without coming to any consensus internally, we left the test as-is (not sending an Accept header).
Last updated: Apr 12 2022 at 19:14 UTC
