/mirrors/bzr.webdav

To get this branch, use:
bzr branch http://suren.me/webbzr/mirrors/bzr.webdav
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
* webdav.py

** We can detect that the server do not accept "write" operations
   (it will return 501) and raise InvalidHttpRequest(to be
   defined as a daughter of InvalidHttpResponse) but what will
   the upper layers do ?

** 20060908 All *_file functions are defined in terms of *_bytes
   because we have to read the file to create a proper PUT
   request.  Is it possible to define PUT with a file-like
   object, so that we don't have to potentially read in and hold
   onto potentially 600MB of file contents?

** Factor out the error handling. Try to use
   Transport.translate_error if it becomes an accessible
   function. Otherwise duplicate it here (bad)

* tests

** Implement the testing of the range header for PUT requests
   (GET request are already heavily tested in bzr). Test servers
   are available there too. This will also help for reporting
   bugs against lighttp.

** Turning directory indexes off may make the server reports that
   an existing directory does not exist. Reportedly, using
   multiviews can provoke that too. Investigate and fix.

**  A DAV web server can't handle mode on files because:

    - there is nothing in the protocol for that (bar some of them
      via PROPPATCH, but only for apache2 anyway),

    - the  server  itself  generally  uses  the mode  for  its  own
      purposes, except  if you  make it run under  suid which  is really,
      really   dangerous   (Apache    should   be   compiled   with
      -DBIG_SECURITY_HOLE for those who didn't get the message).

   That means this transport will do no better. May be the file
   mode should be a file property handled explicitely inside the
   repositories and applied by bzr in the working trees. That
   implies a mean to store file properties, apply them, detecting
   their changes, etc.

   It may be possible to use PROPPATCH to handle mode bits, but
   bzr doesn't try to handle remote working trees. So until the
   neeed arises, this will remain as is.