Please describe the issue thoroughly enough so that anyone can reproduce the exact behavior you’re seeing. Be as specific as possible.
This is a webdav repository service through a QNAP NAS server (HTTP port 5000). Therefore I am not looking to use Caddy for webdav functionalities (via the plugin).
If I try to access to this webdav repository via Caddy (in HTTPS), I can read, create and delete files, but I cannot save any change, otherwise I receive a writing error and the file I tried to changed is renamed as *.0.tmp.
This in practice corrupts the file.
4. Error messages and/or full log output:
Please DO NOT REDACT any information except passwords/keys!
On the webdav client: “Failed to upload”
5. What I already tried:
Accessing the webdav repository via Caddy in HTTP works fine.
After a restart of the webdav server, it seems that the error is no longer there (at least within the LAN in https).
However I cannot confirm yet via caddy as I get problems with the certificates: “Too many certificates already issued for domain”, probably because after each Caddy restart the certificates are deleted and not saved them. By the way, how can I fix this? Can I point in the launch command to a specific folder I know it is not deleted?
I use webdav for KeePass (a password manager), which uses a small file (few Kb) as a database which can be loaded directly through the various KeePass clients. But the error also occurs on simple txt files that I can create for testing purposes with a simple webdav client (CX File Explorer, on Android).
I can reconfirm that with Caddy on HTTP the error does not occur.
Conceptually, Caddy’s reverse proxy is very simple. You make request to Caddy. Caddy notes the particulars of the request. Then it makes a new request to the upstream server. Then it takes the response from the upstream server, and it returns that response to you.
If the site works in a browser when accessed directly, it should work in a browser when proxied through Caddy. Again, the reverse proxy is not very complex conceptually, and neither is a HTTP request. If it doesn’t work on a browser directly, it won’t work in a browser through Caddy.
It might be Caddy related, I just hesitate to say it’s an error in Caddy.
Remember that Caddy’s proxy directive proxies standard HTTP, and that WebDAV is an extension to HTTP (i.e. nonstandard). This might just be a case of the client/server using WebDAV functions that Caddy isn’t handling, I’m not sure - but notably Caddy is similarly unable to fully proxy Remote Desktop Gateway (insofar it uses some kind of MSRPC over HTTP, establishing a tunnel of sorts for RDP communication).
Edit: Looking into this further, I don’t have QNAP specifically, but I do reverse proxy my own Nextcloud instance, which is accessible via WebDAV. Previously I’ve used the Nextcloud client for syncing, but I just tested adding the WebDAV endpoint via Finder on MacOS. Everything’s working fine in that regard, so whether Nextcloud/MacOS Finder are using different methods than QNAP server/QNAP client, I’m not sure… But I was able to add, delete, rename etc. files at random.
Yes, my Nextcloud instance itself is inaccessible except via Caddy (the Docker network is the only network connection it has, with Caddy as the ingress point).
The URL I use in MacOS Finder’s “Connect to Server” window is https://nextcloud.whitestrake.net/remote.php/dav/files/Whitestrake/.
Attempts to connect via HTTP would be issued a redirect to HTTPS.
Another edit: Reviewing my server logs, the vast majority of access to Nextcloud is at this endpoint - implying that the Nextcloud client I’ve been running all this time also uses WebDAV (or at least the WebDAV endpoint) too, and it’s functioning perfectly.