quicker or custom timeouts for .well-known/smart-configuration ? about client-js

[TheTallMan67]

I get the same error from Cerner. Even waiting 1 second is a long time. Is no FHIR service is implementing this should the call even be made in the first place?

[nschwertner]

Since the .well-known/smart-configuration endpoint is part of the spec, it would be expected that the client would query it by default. It would be reasonable though to add some sort of configuration options for adapting better to quirky legacy implementations.

[vlad-ignatov]

.well-known/smart-configuration is expected to become the default way of detecting the auth endpoints and that is why it is tried first. One of the reasons is simply that the CapabilityStatement is too big to download and too slow to parse, just to extract a few strings. I guess nobody would have expected to have to wait so much for 404 response.

I will include some kind of patch for this in the next release soon. So far I think that the best solution might be based on Promise.any, so that both are tried in parallel, no time is wasted and the faster method wins...

If you consider making a PR, please don't. I'm at the end of difficult transition to TypeScript and any PR would be very difficult to merge.

[vlad-ignatov]

This should be fixed in the latest version 2.2.0. Both /metadata and /.well-known/smart-configuration are requested at the same time (in parallel). Whoever arrives first is used, and the other one is canceled. This means that you should experience no slowdowns, and once your Epic instance hosts a .well-known/smart-configuration file, you can expect your app to boot much faster.

BTW, this also lead to adding some new functionality in 2.2.0 - Aborting Requests

I should mention that there is one issue that I stumbled upon:

1. The authorization is optional for a FHIR server. It is valid to have an open server that does not specify an authorize endpoint in it's CapabilityStatement.
2. However, according to the documentation at http://www.hl7.org/fhir/smart-app-launch/conformance/index.html#using-well-known, the authorization_endpoint is required in the well-known json. This means one cannot have an open server with well-known json, does it?

Right now I am following the spec. If the library fetches a well-known json but it does not have authorization_endpoint or token_endpoint, it will be discarded as invalid and the CapabilityStatement will be used.

I hope @jmandel can share his opinion on why authorization_endpoint and token_endpoint are documented as required.