DELETE operations do not handle all success return codes properly

Per RFC 2616 S9.7, 200, 202, and 204 are all valid success responses for a delete operation. For this use case, 202 probably isn't a very good sign (it means the deletion is queued but hasn't taken place yet), but it probably shouldn't be fatal as it currently is. 200 definitely shouldn't produce any error output, as it does currently (a squashed curl_http_error erroneously stating that the delete failed), since it's equivalent to a 204 except for indicting the presence of an entity in the response.