Open robince opened 2 years ago
From here I discovered the Apache server DirectorySlash off
directive, which fixes the issue for me (now uploads as expected).
<Directory "/data/dav/dvc">
DAV On
AuthType basic
AuthName "dvc"
AuthUserFile /data/dav/dvc.passwd
Require valid-user
DirectorySlash off
</Directory>
So can close this issue, but perhaps something could be added to the documentation, or if the trailing slash could still be added to the PROPFIND to ensure standards compliant requests this would avoid the need for this directive.
Thanks for reporting this!
cc @skshetry
Bug Report
push: cannot upload to webdav server
Description
Cannot push to a webdavs remote: "failed to transfer"
Reproduce
Example:
git init
dvc init
echo abcdefg > data
dvc add data
dvc remote add -d webdav webdavs://url/data
dvc remote modify webdav user dvc
dvc remote modify webdav password XXX
dvc push -v
Expected
I expected the file to be uploaded to the remote folder. What happened was the top level folder "02" is created on the server (so no issue with disk write permissions on the server). But no data is uploaded.
Webdav server is working fine with other clients.
Environment information
Output of
dvc doctor
:Server: Centos7, Apache/2.4.6 (CentOS)
Additional Information (if any):
Verbose output on first run (destination directory empty):
Server access log corresponding to the above. There are no server errors.
Folder
02
is created after runing the first push. Then on a second push:If I push to the remote folder over ssh then I can pull succesfully over webdav. It is just uploading files to webdav that fails.
I am not sure why MKCOL seems to be happening before PROPFIND for a folder that exists on the server, and I'm also not sure why PROPFIND is returning a 301. From this perhaps the url should have a trailing slash? (ie
PROPFIND /dav/dvc/02/
- in that post this changed the 301 which I am seeing to a 405. I have tried addingDavDepthInfinity on
but doesn't make any difference to the above (still get 301 on PROPFIND). According to the specs collections should have a trailing slash so I think this could be the reason for the 301 (Moved Permanently).