Stream: conformance
Topic: Delete error codes
Jose Costa Teixeira (Dec 22 2020 at 07:18):
Reading the spec, when we try to delete a non-existing resource, we should get a success code - 200 / 202 / 204 response. (I'd guess a 204?) .
I was asked if this contradicts the RFC7321 which describes that the code 404 can be used also when a server does not want to reveal whether a resource exists.
My take on this is that the 200 is more opaque - it just says that the server accepts to process the delete request, without saying it is an error or not. Is this a correct summay?
Lloyd McKenzie (Dec 22 2020 at 14:14):
@John Moehrke
John Moehrke (Dec 22 2020 at 14:28):
There are many ways that an attacker can infer information thru sending delete requests. An attacker can see different return codes, and could then determine if the resource existed or did not exist. Thus leaking knowledge, however small... As with any access control failure, the actual returned code should be driven by policy. This is especially true for those apps or users without rights to do the action.
The problem is that an authorized app needs to get useful codes so that it can tell if the resource was properly deleted.
THIS does not address your specific situation of an authorized app deleting a non-existing resource... I would still recommend that the client be ready for MANY possible results including 404, 200, 202...
I am not sure how RFC7321 applies. Did you mean this?
So are you proposing that the use-case of an authorized app deleting a non-existent resource be expressed in the spec? Or is the IETF specifications sufficient reference? FHIR should be careful not to overly specify infrastructure that we are based upon..
Jose Costa Teixeira (Dec 22 2020 at 15:26):
The question I was asked is "doesn't this conflict with the RF 7321?"
- I think not, because RFC7321 only specifies the meaning of the codes (even if it leaves space for ambiguous interpretations.
John Moehrke (Dec 22 2020 at 15:28):
I don't think you mean RFC7321... I think you mean RFC7231
Jose Costa Teixeira (Dec 22 2020 at 15:34):
yes. You see why I failed my piano lessons
Jose Costa Teixeira (Dec 22 2020 at 15:39):
Perhaps we can specifically explain that a DELETE of a resource should return a 200 /(or 202?) independently of whether the resource is accessible or not. And a short note why this should not give different response codes for those cases.
Jose Costa Teixeira (Dec 22 2020 at 15:40):
btw, Is it 200 or 202, or up to servers to decide?
IIRC, HAPI returns 200.
John Moehrke (Dec 22 2020 at 15:40):
an authorized app (authorized to interact, but not to delete) should be able to know that the delete did fail because delete is not allowed.
John Moehrke (Dec 22 2020 at 15:42):
that is dependent on if the server completed the delete, or just queued the delete to happen. I presume HAPI always knows that the delete completed. With 200 the resource needs to be gone... with 202 it is possible (small window of opportunity, but possible) that the resource still exists post returning 202
John Moehrke (Dec 22 2020 at 15:43):
a journaled database would tend to just put the delete in a queue and return 202.. or a highly federated database that requires the delete to propigate to many data-centers might also use 202
John Moehrke (Dec 22 2020 at 15:44):
hence... why FHIR should not constrain things... and why clients must be robust (Postel's Law)
Last updated: Apr 12 2022 at 19:14 UTC
