headers
HeCSa | 1 Nov 2007 02:52
Picon

Re: Problems with webdav & unzip


Werner:
   Thanks a lot for your answer!
   The OS I'm using is Red Hat AS 4 Update 5.
   The packages used to mount the davfs2 shares are these:

[root <at> dbserver01 ~]# rpm -qa | grep fuse
fuse-kmdl-2.6.9-55.ELhugemem-2.7.0-3_7.el4
fuse-davfs2-1.2.1-1.el4.rf
fuse-2.7.0-3_7.el4
[root <at> dbserver01 ~]#

   The /etc/fstab is configured in this way:

http://webserver/shared     /mnt/shared    davfs  
uid=oracle,gid=oinstall,dir_mode=770     0 0

   The /etc/davfs2/davfs2.conf contents (all but commented) are these:

dav_user        oracle
dav_group       dba

   I was looking for the debug option on the davfs2.conf man page, but I
didn't found anything. How do I enable it?

   Thanks a lot!!!

HeCSa.

>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Werner Baumann | 1 Nov 2007 10:47
Picon

Re: Problems with webdav & unzip


As the issue is not about the WebDAV Protocol, but about davfs2 and 
apache, please create a bugreport on
http://sourceforge.net/projects/dav/

Pleas include all the information from your previous mails. Additionally
- server version and vendor
- entries from the apache *access*-log related to the "unzip 
plano.zip"-command.

Werner
Permalink | Reply | 2 comments |
headers
Werner Donné | 9 Nov 2007 10:41
Picon

The use of status code 506 (Loop Detected)


Hi,

In the bindings draft the status code 506 is introduced as a
possible response for the PROPFIND method. Is it allowed to
use the status code for other methods as well?

The use-case is a server which doesn't allow the creation of
loops. When an operation would create a loop the status code
could be used to report it. When a server supports bindings
a sequence of MOVE methods could create a loop for example.

Regards,

Werner.
--

-- 
Werner Donné  --  Re                                     http://www.pincette.biz
Engelbeekstraat 8                                               http://www.re.be
BE-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne <at> re.be
Permalink | Reply | 4 comments |
headers
Julian Reschke | 9 Nov 2007 11:37
Picon
Picon

Re: The use of status code 506 (Loop Detected)


Werner Donné wrote:
> 
> Hi,
> 
> In the bindings draft the status code 506 is introduced as a
> possible response for the PROPFIND method. Is it allowed to
> use the status code for other methods as well?

I'd say yes, as long as the error is the one defined for 506 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#status.506.loop.detected>):

"The 506 (Loop Detected) status code indicates that the server 
terminated an operation because it encountered an infinite loop while 
processing a request with "Depth: infinity". This status indicates that 
the entire operation failed."

> The use-case is a server which doesn't allow the creation of
> loops. When an operation would create a loop the status code
> could be used to report it. When a server supports bindings
> a sequence of MOVE methods could create a loop for example.

I think it would be better to return a 409 with 
DAV:error/DAV:cycle-allowed here.

BR, Julian
Permalink | Reply | 3 comments |
headers
Julian Reschke | 9 Nov 2007 14:29
Picon
Picon

Re: The use of status code 506 (Loop Detected)


Julian Reschke wrote:
> ...
> I think it would be better to return a 409 with 
> DAV:error/DAV:cycle-allowed here.
> ...

...that being said, I wouldn't be opposed to adding an appendix that 
both illustrates how MOVE requests can theoretically generate a bind 
cycle, and how to handle that case.

BR, Julian
Permalink | Reply | 2 comments |
headers
Werner Donné | 10 Nov 2007 09:12
Picon

Re: The use of status code 506 (Loop Detected)


Say we have the path /A/B/C/D/ where D/ is in fact a second
binding to /A/E/F/. If you move /A/B/ to /A/E/F/ you get
/A/E/F/B/C/D/. Because of the binding this is the same as
/A/E/F/B/C/F/, which is a loop. Note that we did a move of B/,
which is not involved in any binding itself.

It is also possible to introduce a second binding to a resource
without actually supporting the BIND method. Let's take a versioning
server, for example, with auto-version set to manual for /A/B/
and /A/C/. Say we want to move /A/B/D to /A/C/D. We have to
check out /A/B/ and /A/C/, provided we support versioning of
collections. After the move we check in /A/C/, but we undo the
check-out of /A/B/. We are then left with /A/B/D and /A/C/D,
both referring to the same resource.

So loops could occur without the binding spec being supported.

Regards,

Werner.

Julian Reschke wrote:
> Julian Reschke wrote:
>> ...
>> I think it would be better to return a 409 with 
>> DAV:error/DAV:cycle-allowed here.
>> ...
> 
> ...that being said, I wouldn't be opposed to adding an appendix that
(Continue reading)

Permalink | Reply | 1 comment |
headers
Julian Reschke | 10 Nov 2007 12:26
Picon
Picon

Re: The use of status code 506 (Loop Detected)


Werner Donné wrote:
> Say we have the path /A/B/C/D/ where D/ is in fact a second
> binding to /A/E/F/. If you move /A/B/ to /A/E/F/ you get
> /A/E/F/B/C/D/. Because of the binding this is the same as
> /A/E/F/B/C/F/, which is a loop. Note that we did a move of B/,
> which is not involved in any binding itself.

Yep.

Essentially it can occur anytime a collection is moved below another 
collection a descendant already binds to.

A simpler example would be (set your mail reader to monospaced font...):

We start with the root collection, and just two collections C1 and C2:

                  +------------------+
                  | Root Collection  |
                  |  bindings:       |
                  |  CollX    CollY  |
                  +------------------+
                      |          |
                      |          |
         +------------------+    |
         | Collection C1    |    |
         |  bindings:       |    |
         |           CollZ  |    |
         +------------------+    |
                      |          |
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Reschke | 10 Nov 2007 18:34
Picon
Picon

RFC4918 erratum (If header)


Hi,

<http://tools.ietf.org/html/rfc4918#section-10.4.7> says:

10.4.7.  Example - Using "Not" with No-tag Production

      If: (Not <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
      <urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092>)

    This If header requires that the resource must not be locked with a
    lock having the lock token
    urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2 and must be locked by a
    lock with the lock token
    urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092.

In the example, the second line needs to be indented by at least one 
space, for instance:

      If: (Not <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
           <urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092>)

BR, Julian
Permalink | Reply | 0 comments |
headers
Julian Reschke | 11 Nov 2007 20:32
Picon
Picon

BIND spec status


Hi,

the BIND spec has been in status "publication requested" for quite some 
time now 
(<https://datatracker.ietf.org/idtracker/draft-ietf-webdav-bind/>). 
Unfortunately, nothing else has happened with it so far.

To those who want to see it finally published: it probably makes sense 
to review both draft-19 
(<http://www.webdav.org/bind/draft-ietf-webdav-bind-19.html>) and give 
feedback on the current contents to the responsible Area Director, Chris 
Newman.

In the meantime, some feedback was received from Yaron Goland (one of 
the authors of RFC2518). It seems there are three clarifications we 
should do (which will not make any changes to normative parts of draft 19).

While doing this, I'd also like to address the question raised by Werner 
Donné.

See subsequent mails for the individual issues.

BR, Julian
Permalink | Reply | 0 comments |
headers
Julian Reschke | 11 Nov 2007 20:39
Picon
Picon

BIND issue: 3.1-clarify-resource-id


(see 
<http://www.webdav.org/bind/draft-ietf-webdav-bind-latest.html#rfc.issue.3.1-clarify-resource-id>)

This one came up when Yaron asked for a way to create a new binding 
without risking a race condition (where the URI given in the <href> 
element is re-mapped to a different resource in the meantime).

Turns out that BIND does not require the <href> to use an HTTP URI -- so 
it would be possible to use the value of the DAV:resource-id instead, 
such as in

BIND /CollY HTTP/1.1
Host: www.example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: xxx

<?xml version="1.0" encoding="utf-8" ?>
<D:bind xmlns:D="DAV:">
    <D:segment>bar.html</D:segment>
    <D:href>urn:uuid:6ed638d6-908d-11dc-9f44-0015c5140153</D:href>
</D:bind>

Of course that may not be possible with all servers (basically it 
requires the server to be able to internally *resolve* the resource-id).

This may not been clear previously, so the proposal is to add the 
following note to the definition of DAV:resource-id:

"Note: by definition, the URI specified in the DAV:resource-id property
(Continue reading)

Permalink | Reply | 1 comment |

Gmane