exact webdav settings unclear

[whysthatso]

on a vanilla install on linux and ios i am trying to get webdav going.

so i try to add an account by adding my dav server details like so:

https://dav.domain.com/subfolder (the subfolder is already an assumption i took)

presumably user/pass are for basicauth? so i enter user pass

i'm running the dav module of nginx with a basicauth restricted location, that's all.

when connecting i get an error 'failed to connect...'

however, serverside, i see the creation of some temporary test folders and files whenver i click on ok, so the connection obviously works, but maybe something did not turn out as expected from the testing? i see for example:

tmp-SynqClient-ServerTests-81a21fd5-9181-41b6-bb42-c5d5035de4c5
 \subfolder
  \test.txt > 'Server Test'

any hints what could fix that test?

[mhoeher]

Hi @whysthatso,

thanks for opening this issue and sorry for replying a bit late - the last days were a bit packed...

Regarding the problem you see: This could well be another incarnation of WebDAV madness :disappointed: The basic problem: While there's a WebDAV standard, support for it on client and server side heavily varies. In particular, I already encountered several WebDAV servers that do not (properly) implement all the needed parts that are needed to get a smooth synchronization done...

If you see some temporary files/folders being created, this is actually a good sign: It means, that basically we can connect to the server. However, during the tests that OpenTodoList runs against the server to learn if it is suitable to run a proper sync, something probably fails - and hence, consequentially the app refuses to add the account.

I've not yet checked nginx's DAV module, but I know that e.g. also Apache's mod_dav does not properly support all the needed stuff for a proper sync. However, for Apache, there are some workarounds in place (although the sync is not as efficient as against a properly functioning server).

I'll try to check nginx as soon as I somehow can. However, it could take a bit until I can do so, sorry.

In the meantime, maybe you could try to set up e.g. NextCloud or ownCloud (if you have the server under control). Both are known to implement the WebDAV protocol properly (for sync) and running a sync against them is even part of the CI/CD testing done for OpenTodoList - so you should get a nice user experience using this as backend.

[mhoeher]

Just for the records: I created an issue over at GitLab to track this issue (this is where the app is mainly developed :wink:).

[mhoeher]

Hi @whysthatso,

first of all happy new year and sorry for the long silence!

I had a look at the issue and tried to reproduce locally running the unit tests of the SynqClient library (which is the library used by OpenTodoList for the sync) against an nginx server (in particular, I used the docker image provided by this project: https://github.com/dgraziotin/docker-nginx-webdav-nononsense).

In fact, the server seems to be unsuitable for running a sync: Apart from some "usual suspects" (e.g. no etags are reported when uploading files, which means sync conflicts might occur more often with that server), I noticed that the server does not report etags when listing remote files. This, however, is a total no-go, as it means the app cannot efficiently discover remote updates.

I am not an expert with nginx, but I think you could do one of the following:

1. Check if you can configure nginx to include etags when a (recursive) PROPFIND request is made against the server. As stated, I am absolutely no expert with nginx, but is seems there is an abundance of configuration options available - maybe it could be tuned to be usable for proper file synchronization.
2. Or (and this would probably give you a far smoother sync experience) install NextCloud or ownCloud, which provide a pretty complete and functional WebDAV interface.

Sorry that I cannot provide any better news for you right now. Please let me know if you need any more help on this.