Stream: conformance
Topic: HTTP 401 or 403?
Ardon Toonstra (Dec 09 2020 at 15:53):
The FHIR search spec states to use a 403 while the FHIR http spec states a 401 and places a '?' after the 401 in the summary.
Is this an inconsistency worth filing a ticket for?
Gino Canessa (Dec 09 2020 at 16:39):
I'd say it does. However, I think it's only necessary to add 403 to the http page as a 'common response' (for both 3.1.0.9 and 3.1.0.17); the search page has the qualification:
while other
4xxand5xxcodes signify that some sort of error has occurred
Vassil Peytchev (Dec 09 2020 at 16:42):
Yes, the two spots seem to be complementary. Sounds like 401 must be returned for authorization errors, and 403 is for other types of a refusal "to perform the search".
John Moehrke (Dec 09 2020 at 17:19):
which code is returned will be strongly influenced by policy. Should not be fixed in an HL7 specification.
John Moehrke (Dec 09 2020 at 17:20):
https://www.hl7.org/fhir/security.html#AccessDenied
Gino Canessa (Dec 09 2020 at 17:27):
Yep, the tables on http.html are 'common responses' - so just hints to implementers as to what they should expect.
John Moehrke (Dec 09 2020 at 17:29):
a bit more strong than that... it is what they must be able to handle. -- that is under Postel's Law of Robustness
John Moehrke (Dec 09 2020 at 17:29):
we really need a Postel's law mechanism in our structureDefinitions...
Gino Canessa (Dec 09 2020 at 17:40):
I'm confused - it sounds like you're arguing that we shouldn't specify in the standard, but we also need to specify the codes in the standard. What am I missing?
The list under 3.1.0.9 has a heading of: Common HTTP Status codes returned on FHIR-related errors.... The table at the end is just a summary of those common codes (though it could use clearer labelling). A robust client will need to handle more than listed (e.g., no 5xx codes are listed), but I don't think we need to call out each one.
Last updated: Apr 12 2022 at 19:14 UTC
