Distinguish 503 Storage not available from 503 Service unavailable

[PVince81]

See owncloud/core#9376

From the introduction of server to server sharing, it can happen that a specific mount point is not available so any operation on that folder would return "503 Storage not available".

Currently the sync client shuts down itself (gray) and stops syncing, believing that the whole server is down.

@ogoffart suggested this needs to be fixed in a later version of the sync client.

[guruz]

@ogoffart As discussed also make sure that 503 is never blacklisted as it is supposed to be the temporary answer from the server.

[dragotin]

We shouldn't probably blacklist 5xx bugs at all. Currently we do not very much verify the http error code, see src/libsync/owncloudpropagator.cpp, line 94, it blacklists everything.

[guruz]

@dragotin I remember some months ago we had the same discussion and @ogoffart and you said that 500 should not be blacklisted because the server might go bonkers on a file and then it would be re-uploaded all the time.

@DeepDiver1975 @PVince81 Do you have an opinion on this?
I also favor not blacklisting 5xx at all.

[PVince81]

Can you remind us what the purpose of the blacklist is ?
There's another ticket where people asked for removing it completely.

From what I understand it's mostly to avoid retrying the same broken file over and over again and annoy the user with error messages in the popup ?

[DeepDiver1975]

Can you remind us what the purpose of the blacklist is ?
There's another ticket where people asked for removing it completely.

This is about client side blacklisting - totally unrelated to our server blacklist.
On the client the blacklist contains files which are not to be synced - e.g. files with unsupported file names or where the server told the client to nolonger sync them because of they violate any kind of pattern (e.g. invalid file size or type - which is used in some enterprise environments)

[guruz]

files with unsupported file names or where the server told the client to nolonger sync them because of they violate any kind of pattern (e.g. invalid file size or type - which is used in some enterprise environments)

The question is if all possible storage backends return a 4xx for those kind of error or a 5xx.
If the latter, then we'll continue to blacklist 5xx but distinguish the 503 (and maybe some others the server guys tell us)

[guruz]

Reminder: Maybe the update phase of csync must also handle the 503 Storage Unvailable differently. Currently it would abort the whole sync.
Question is if we need to do better, why would the storage be unavilable. Sysadmin should fix it :-)

[PVince81]

One reason for example is if you connect to a remote ownCloud, SFTP or sharepoint, and the remote password has changed, in which case we also return 503 unavailable.
Or maybe at some point there are connectivity issues.

[PVince81]

There are also discussions about providing an offline mode for storages in the future: owncloud/core#11149

[dragotin]

If the server could send the directory for which the 503 is valid, we could set it to ignore... maybe. @PVince81 would that be feasible?

[PVince81]

In what way would the it be sent ?

Currently in my test case I have a folder "/oc" which returns 503 when you do any operations on it.
However running PROPFIND on "/" will work fine (after owncloud/core#11791 is merged)

In what part of the discovery should information be returned ?

[dragotin]

This branch proposes a fix for this problem: https://github.com/owncloud/mirall/tree/fix_service_unavailable

[DeepDiver1975]

please keep in mind that due to e.g. upgrade we will respond with 503 at any time - you cannot rely on the resource type you are asking for.

the clean solution would be to have dedicated status codes for dedicated situations

[ogoffart]

well, 503 on status.php will abort the sync anyway.

[DeepDiver1975]

well, 503 on status.php will abort the sync anyway.

sure - but it can happen during any other sync step as well and you can make no assumption about the reason

[ckamm]

I'm closing this ticket because we handle

• 503 Storage not available during discovery and
• regular 503 during connection pings

correctly now.

A upgrade-induced 503 during discovery or up/downloads will lead to a sync failure. I'll make a new ticket to track and discuss that issue.