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

1 files changed, 28 insertions, 13 deletions

diff --git a/doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__/comment_2_72e9ecc6acdc555e36f5588120d070fa._comment b/doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__/comment_2_72e9ecc6acdc555e36f5588120d070fa._comment
index 2c1ebeda0..8df1c736d 100644
--- a/doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__/comment_2_72e9ecc6acdc555e36f5588120d070fa._comment
+++ b/doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__/comment_2_72e9ecc6acdc555e36f5588120d070fa._comment
@@ -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.
 """]]