Consistent gdkdel response across cloud providers when object not found

AWS returns HTTP 204 (No content) for an object delete when the object is not found. The 204 HTTP response is a successful HTTP response (200 series) and due to that, gdkdel returns its successful return code 0.

The gdkdel API documents the following return code:

There is not caveat to a difference of behavior in the documentation and tracing must be used (if the user doesn't already know) to understand AWS does not return a HTTP 404 in this situation.

CDA only returns the 900 documented when the cloud provider returns HTTP 404 for the request. Some cloud providers do that. CDA does not abstract the HTTP 204 from AWS into a common gdkdel return code so that applications can rely on a common behavior across cloud providers.

I believe CDA really has no way to distinguish between object deleted and object wasn't there in the first place.

My guess is AWS returns HTTP 204 so AWS can always return the same code and the request is idempotent. Also, this approach follows RESTful design principles that the ending resource state is as requested at the completion of the request (i.e. the object doesn't exist at the end of the delete either because the request removed it or because the object wasn't there in the first place).

A workaround is to gdklist first, then gdkdel, then gdklist again. If the first gdklist returns 900, then don't issue the gdkdel. The second gdklist would just be for positive verification the object was deleted. There are some timing windows here if the object name is used in multiple threads of execution, but those exist anyhow when multiple processes are deleting and creating the same object name in the same bucket.

The benefit to creating a common return code for gdkdel when the object does not exist is that CDA users can be generic with respect to the cloud provider without specific code when accessing AWS versus another cloud provider.

If this cannot be done for AWS then I would suggest additional documentation/explanation about the different behavior for this cloud provider.