Hi!
I get the 412 Precondition Failed error when I try to rename or move something via the embedded WebDAV server over HTTPS.
CyberDuck shows the error "Unexpected response (412 Precondition Failed)."
I tried to connect using the hostname, IP address, and WebDAV port proxying via SSH. The result is the same everywhere.
How can I understand why this is so?
[Help] WebDav 412 HTTP error
Re: [Help] WebDav 412 HTTP error
I also get this error over HTTP webdav.
BUT if I connect webdav as a folder in the TOS itself at 127.0.0.1:port, then it can rename and move files without this error.
BUT if I connect webdav as a folder in the TOS itself at 127.0.0.1:port, then it can rename and move files without this error.
Re: [Help] WebDav 412 HTTP error
It seems that the webdav client built into TOS does not fully comply with the standard and therefore works
Re: [Help] WebDav 412 HTTP error
What model and system version are you currently running?
To contact our team, please send email to following addresses, remember to replace (at) with @
Technical team: support(at)terra-master.com(for technical support)
Service team: service(at)terra-master.com(for purchasing, return, replacement, RMA service)
Technical team: support(at)terra-master.com(for technical support)
Service team: service(at)terra-master.com(for purchasing, return, replacement, RMA service)
Re: [Help] WebDav 412 HTTP error
model F8
ver 6.0.673
I debugged through curl and found out that this is because the clients (macOS finder and Cyberduck) send the Overwrite:F header if the new file name does not exist and then the webdav server rejects the request. If you force Overwrite:T, then renaming and moving works.
It seems that this is incorrect server behavior. If Overwrite:F and the target file does not exist, this should work.
ver 6.0.673
I debugged through curl and found out that this is because the clients (macOS finder and Cyberduck) send the Overwrite:F header if the new file name does not exist and then the webdav server rejects the request. If you force Overwrite:T, then renaming and moving works.
It seems that this is incorrect server behavior. If Overwrite:F and the target file does not exist, this should work.