1 - joplin uses non-standard file extensions for the data files. Some web servers do not have MIME type mappings for .md files or files with no extension, so these files will not serve by default. Appreciate it may be hard to change now, but is surely a problem that many will encounter when trying to setup webdav sync
2 - Hugely compounding the above! Joplin is ignoring HTTP response codes when retrieving elements/resources. For instance, download attachment on demand on a sync client may be served a proper 404 file not found by the server, but Joplin client / sync will silently ignore that, log no error, and store that 404 page as the requested resource. Makes figuring out what is going wrong quite hard. Checking of HTTP response codes during these operations and logging them or displaying some sort of error is pretty essential. And of course, a HTTP error page should not be stored as the valid data/resource file.
Just a little feedback based on the issues I have had trying to get Joplin clients to play nice.
If anyone is interested, I wrote a guide to getting this to work, given it took some time. Let me know if interested and I can post a link if that is allowed
It sounds a bit like you're using a non-standard webdav server. I can answer these questions:
joplin uses non-standard file extensions for the data files
Markdown and no-extension are not exactly "non-standard", but anyway a webdav server must be able to handle any arbitrary file extension - there's nothing in the webdav spec that says it should only accept certain extensions and not others.
For instance, download attachment on demand on a sync client may be served a proper 404 file not found by the server, but Joplin client / sync will silently ignore that, log no error, and store that 404 page as the requested resource.
This is of course incorrect, or sync would be completely unusable with WebDAV. We'd need to see the log of a specific request to comment but for sure this is again something strange that your server is doing (and from experience there are many terrible webdav implementations out there).
My guess is that it returns a web page with a 404 message on it but with "200 OK" http status code, so Joplin correctly stores this as the resource since the server responded that it was OK. We can't guess that just because there's a number "404" somewhere in that resource content it means it's an error.
Re the return codes. I checked the web server logs. A 404 response is definitely being served. I checked with listening to the HTTP traffic to, and via manual requests, emulating the joplin request. In each case a 404 appears to be served and joplin actually stores that 404 error page as the resource downloaded.
With regards to the extensions, webdav worked perfectly fine in all cases, it is the web server GET requests that fail due to missing mime types on those extensions for the data files when joplin was fetching the resource attachments. For instance, on IIS, joplin webdav simply will not work, ever, unless you manually add those mime types. The issue is, Joplin never throws any sort of errors I could see, so it's kind of hard for a newbie to figure any of this out (and even took me some hours over days to figure out all the wrinkles).
I supplied the log files in an earlier post a few weeks back which got no responses. I also put them in a bug report on the repository, where someone was nice enough to respond and give me a few pokes in the right direction. No errors were reported by Joplin as far as I could see. The IIS server clearly serves 404 response, though, according to it's own logs and the dev options in Chrome.
Anyhow - These were just a comment on my experience in configuring it, mainly in case it helps others (and surely a Windows webdav setup IS NOT out of the box or straightforward). I have it working now. I shared a guide for others. I hope it helps someone. Thank you.