mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

webdav: When testing the WebDAV server, send a file with content. The empty file it was sending tickled bugs in some php WebDAV server.

Browse source
This commit is contained in:
Joey Hess 2015-12-11 12:13:20 -04:00
parent 48bc7a9057
commit 0f126440ca
Failed to extract signature
3 changed files with 31 additions and 14 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
Remote/WebDAV.hs
View file

@ -191,7 +191,7 @@ testDav url (Just (u, p)) = do
makeParentDirs
void $ mkColRecursive tmpDir
inLocation (tmpLocation "git-annex-test") $ do
putContentM (Nothing, L.empty)
putContentM (Nothing, L8.fromString "test")
delContentM
where
test a = liftIO $

2
debian/changelog vendored
View file

@ -1,6 +1,8 @@
git-annex (5.20151209) UNRELEASED; urgency=medium
* Add S3 features to git-annex version output.
* webdav: When testing the WebDAV server, send a file with content.
The empty file it was sending tickled bugs in some php WebDAV server.
-- Joey Hess <id@joeyh.name> Thu, 10 Dec 2015 11:39:34 -0400

41
doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__/comment_2_72e9ecc6acdc555e36f5588120d070fa._comment
View file

@ -5,20 +5,35 @@
content="""
The first failure is git-annex sending MKCOL (make directory basically).
The server fails with "Unauthorized". You say it also made the directory.
That's got to be a bug in the server, no? It can't sanely have an authorization
problem and also go on and do the unathorized action.
That's got to be a bug in the server, no? It can't sanely have an
authorization problem and also go on and do the unathorized action.
(Sounds rather like a security hole..)
The second failure is git-annex sending PUT. This is the most basic
operation for webdav server to support AFAIK,
and it fails with "NotImplemented".
As to the PUT failure, the chunked transfer encoding mentioned in that
comment is a regular part of the HTTP protocol (this is not connected
to git-annex's own chunking).
<https://en.wikipedia.org/wiki/Chunked_transfer_encoding>
It's also kind of telling that the webdav server
has a message baked into it about not working with the OSX Finder.
Overall, this seems a very bad webdav server.
Looks like this PHP webdav server might be delegating the actual HTTP
to whatever web server it's running on somehow. Since chunked transfer
encoding might not be supported by some web server, they are left trying to
detect that. I don't know if their check for that is accurate.
If you were able to upload files using a different webdav client,
I guess that client must have used a command other than PUT, or
done something else different with the protocol. If you can track down
details of how the client manage to talk to this strange server, we could
see about supporting it.
As to the implementation in git-annex,
Network.Http.Client.RequestBodyStreamChunked is documented to be the only
thing that causes a chunked request body to be sent, and git-annex is using
RequestBodyLBS instead. Unless the documentation is wrong (and I also
looked at the http-client source code and the documentation seems accurate),
I am doubtful that the chunked transfer encoding is actually being used by
git-annex. If eg a protocol dump shows that it is in fact using chunked
transfer encoding (ie, contains "Transfer-Encoding: chunked"),
that would be grounds to file a bug on the http-client library.
Aah, but.. git-annex is sending an empty file. And the webdav server's
check consists of reading 1 byte.
Of course there's not a byte to read if an empty file is being sent!
So that code you showed is certianly buggy.
I've changed git-annex to send a non-empty file when testing the webdav
server to work around this.
"""]]