Imposibility to forward connectivity issues from an external storage to ownCloud clients

[jvillafanez]

There could be issues in the connection between ownCloud and the external storage, such a server down, network temporary cut, etc.
We can detect this kind of issue in the external storage plugin and rise an exception to the core, but there is no specific exception to be risen here.

If we use another exception to send an error to the client (a "not found" exception for example) the behaviour could be different than the user expects (which probably will be not to take any action at all).

I think a new exception is needed so these kind of errors are correctly propagated to clients.

Thanks!

[karlitschek]

@PVince81

[DeepDiver1975]

I did discuss this with @icewind1991 some time back - but I think we did not come up with a final solution.

From a pure http status code interpretation point of view 404 still seems legit as it stats that the reason could also be temporary:

10.4.5 404 Not Found

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable. 

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

[jvillafanez]

From my point of view, if I, as a sync client, ask for a file "file1" and I receive a 404, what I understand is that "file1" doesn't exists in the server, so if I have the file locally, I should delete it.

As a file provider, if I have a connectivity issue to an external storage, I want to tell the client that it's a temporary issue in order to prevent the client to do any action such as delete the file.

[PVince81]

How about 503 Service Unavailable ?

[jcfischer]

We have had the same issue when our primary storage (an NFS server) became unavailable. OwnCloud re-created the initial default folders, the sync clients deleted everything on the local machines and cleaned up the filecache table as well. We had to restore a database backup to get things working again.

I would vote for a 503 (that way, that server would drop out of our load balancer and no further harm is done)

[DeepDiver1975]

How about 503 Service Unavailable ?

In this case the whole sync process will stop because at the moment the assumption is that the server itself is in maintenance mode. In case where an external mounted folder is not available there is no need to stop the whole sync process but to just ignore that specific folder.

@dragotin @danimo as we are talking about sync please add your comments and thoughts - thx

[jvillafanez]

503 might be too tough as stated by DeepDiver1975. It works from the external storage to ownCloud but I'm not sure if it will work fine from ownCloud to the client. Unless we tell the client that the error code is just for the folder and it can keep syncing other folder, it might not be an idea good enough.

To give more ideas:

422 Unprocessable Entity (WebDAV; RFC 4918)
The request was well-formed but was unable to be followed due to semantic errors.

That would require twisting the meaning of the error, but it might fit.

And the other option is to create a custom error code, because I don't think other standard error codes can fit.

[PVince81]

We already have 503 unavailable for "ownCloud" mounts. But I'm not sure all backends properly detect such cases. I raised #11792 to look into this.

[RobinMcCorkell]

Closing in favour of #11792