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

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

View file

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

2
debian/changelog vendored
View file

@ -1,6 +1,8 @@
git-annex (5.20151209) UNRELEASED; urgency=medium git-annex (5.20151209) UNRELEASED; urgency=medium
* Add S3 features to git-annex version output. * 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 -- Joey Hess <id@joeyh.name> Thu, 10 Dec 2015 11:39:34 -0400

View file

@ -5,20 +5,35 @@
content=""" content="""
The first failure is git-annex sending MKCOL (make directory basically). The first failure is git-annex sending MKCOL (make directory basically).
The server fails with "Unauthorized". You say it also made the directory. 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 That's got to be a bug in the server, no? It can't sanely have an
problem and also go on and do the unathorized action. 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 As to the PUT failure, the chunked transfer encoding mentioned in that
operation for webdav server to support AFAIK, comment is a regular part of the HTTP protocol (this is not connected
and it fails with "NotImplemented". to git-annex's own chunking).
<https://en.wikipedia.org/wiki/Chunked_transfer_encoding>
It's also kind of telling that the webdav server Looks like this PHP webdav server might be delegating the actual HTTP
has a message baked into it about not working with the OSX Finder. to whatever web server it's running on somehow. Since chunked transfer
Overall, this seems a very bad webdav server. 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, As to the implementation in git-annex,
I guess that client must have used a command other than PUT, or Network.Http.Client.RequestBodyStreamChunked is documented to be the only
done something else different with the protocol. If you can track down thing that causes a chunked request body to be sent, and git-annex is using
details of how the client manage to talk to this strange server, we could RequestBodyLBS instead. Unless the documentation is wrong (and I also
see about supporting it. 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.
"""]] """]]