Three annoying things with pyWebDav and one showstopper

[GoogleCodeExporter]

1) The WebDav methods MOVE and COPY do not work for folders if pyWebDAV is 
listening on localhost. With files however they do work. The log shows errors 
of several functions and that one below:
"IOError: [Errno 2] No such file or directory: '/<source 
path>/http:/localhost:8008/<destination path>/<a file inside>'". This error 
line should give you the clue! Note the part starting with "http:/". When this 
error was reported absolutely nothing in the request header referred to 
localhost! I suppose that the file path is built incorrectly if localhost is 
used.

The issue can be worked around by making pyWebDAV listen on the local ethernet 
adapter, but while pyWebDAV practically cannot be run with user credentials (it 
only accepts one user and even if patched to accept a .htpasswd file it would 
lack features to show the different users different base folders - This kind of 
feature can only be worked around with a reverse proxy like nginx in front) 
this of course opens a giant security leak.

2) OK, somewhere on the internet you can find a solution for the problem that 
pyWebDAV always runs as the user that started the tool. But what you can find 
nowhere is how to set the group and the access rights of files created! Should 
be made able to be set via cmdline, too.

3) My NAS has exactly 1MB (RAM) on /tmp (and /var). So, for sure that is not 
the right place for bloaty logs to go to in "daemonize" mode, right? Please 
allow this to be set via cmdline options. 

I currently work this (and the rights part of issue 2) around with the 
following commandline: "su -c "(umask 0; davserver -D <basedir> -n -H <anything 
except localhost!> >/dev/null 2>&1 &)" <user>". The group part of issue 2 can 
not be worked around on my machine because it seems to have a version of sudo 
that does not yet support that... any ideas (because other tools like nginx 
still manage to set the run-as-GID)?

4) pyWebDav seems to use only memory for file transfers. This is extremely 
sub-optimum for a tool that obviously is targeting minimum size systems, like 
e.g. my NAS. Everybody who has a system with huge memory for sure will rely on 
the much more bloated solutions like ownCloud, Apache, or the like. On my 
system I better not transfer files greater than 60MB with pyWebDAV, because it 
not only will last for close to ever to complete, or simply even crash, but 
will wear down my flash memory (configured as swap space) very quickly, too.

Currently I work this around by adding nginx as a proxy and let him do the PUT 
and GET methods. But I guess that in this case I will loose LOCK functionality, 
right? => Showstopper!

Original issue reported on code.google.com by [email protected] on 21 Dec 2013 at 10:01