Resolving BIND issue: 5.1_506_STATUS_STREAMING, other open BIND issues?

Hi,

to resolve the only remaining open (recorded) issue with the BIND spec 
(issues list: [1], actual issue: [2]), we (Geoff and I) propose to 
simply allow the 506 error code to appear within the multistatus 
element. Note that there doesn't seem to be an implementable alternative 
short of either forbidding bind loops or servers streaming multistatus 
reponses upon Depth:infinity (the revised section is attached below).

The only other issue I'm sort-of aware of is Lisa Duseault's concern 
about locking semantics when multiple bindings exist to a locked 
resource, voiced during the Seoul meeting (transcript at [3]).

IMHO this was dicussed here before, and the answer simply is that these 
concerns are invalid. A WebDAV lock both locks the resource (directly) 
and protects it's URI (indirectly). Given two bindings "a" and "b" to 
the same resource, you can't use "b" to modify it after it has been 
locked through "a" (because it's the resource that is locked). However 
you *may* DELETE or MOVE "b" (because that binding is not protected by 
the lock requested on "a").

This is the locking behaviour described in RFC2518, and clarified im 
GULP [4].

Note that multiple bindings to the same resource can exist independantly 
of the BIND spec (for instance as result of DeltaV operations). All the 
BIND spec adds is

- clarifying discovery of bindings
- clarify behaviour of bindings in face of namespace operations, incl 
error handling
- adding explicit operations to create new bindings

As the question seems to be re-raised every few months, I'll now add it 
(as "resolved") to the document's issues list.


Regards, Julian


[1]
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html>
[2] 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.5.1_506_STATUS_STREAMING>
[3]
<http://www.xmpp.org/ietf-logs/webdav@ietf.xmpp.org/2004-03-01.html>
[4]
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0001.html>

- Revised section:

7. Additional Status Codes

7.1 208 Already Reported

    The 208 (Already Reported) status code can be used inside a
    DAV:propstat response element to avoid enumerating the internal
    members of multiple bindings to the same collection repeatedly.  For
    each binding to a collection inside the request's scope, only one
    will be reported with a 200 status, while subsequent DAV:response
    elements for all other bindings will use the 208 status, and no
    DAV:response elements for their descendants are included.

    Note that the 208 status will only occur for "Depth: infinity"
    requests, and that it is of particular importance when the multiple
    collection bindings cause a bind loop as discussed in Section 2.2.

    A client can request the DAV:resourceid property in a PROPFIND
    request to guarantee that they can accurately reconstruct the binding
    structure of a collection with multiple bindings to a single
    resource.

    For backward compatibility with clients not aware of the 208 status
    code appearing in multistatus response bodies, it SHOULD NOT be used
    unless the client has signalled support for this specification using
    the "DAV" request header (see Section 8.2). Instead, a 506 status
    should be returned when a binding loop is discovered. This allows the
    server to return the 506 as the top level return status, if it
    discovers it before it started the response, or in the middle of a
    multistatus, if it discovers it in the middle of streaming out a
    multistatus response.

7.1.1 Example: PROPFIND by bind-aware client

    For example, consider a PROPFIND request on /Coll (bound to
    collection C), where the members of  /Coll are /Coll/Foo (bound to
    resource R) and /Coll/Bar (bound to collection C).

    >> Request:

    PROPFIND /Coll/ HTTP/1.1
    Host: www.example.com
    Depth: infinity
    DAV: bind
    Content-Type: text/xml; charset="utf-8"
    Content-Length: xxx

    <?xml version="1.0" encoding="utf-8" ?>
    <D:propfind xmlns:D="DAV:">
       <D:prop> <D:displayname/> </D:prop>
    </D:propfind>

    >> Response:

    HTTP/1.1 207 Multi-Status
    Content-Type: text/xml; charset="utf-8"
    Content-Length: xxx

    <?xml version="1.0" encoding="utf-8" ?>
    <D:multistatus xmlns:D="DAV:">
       <D:response>
          <D:href>http://www.example.com/Coll/</D:href>
          <D:propstat>
             <D:prop>
                <D:displayname>Loop Demo</D:displayname>
             </D:prop>
             <D:status>HTTP/1.1 200 OK</D:status>
          </D:propstat>
       </D:response>
       <D:response>
          <D:href>http://www.example.com/Coll/Foo</D:href>
          <D:propstat>
             <D:prop>
                <D:displayname>Bird Inventory</D:displayname>
             </D:prop>
             <D:status>HTTP/1.1 200 OK</D:status>
          </D:propstat>
       </D:response>
       <D:response>
          <D:href>http://www.example.com/Coll/Bar</D:href>
          <D:propstat>
             <D:prop>
                <D:displayname>Loop Demo</D:displayname>
             </D:prop>
             <D:status>HTTP/1.1 208 Already Reported</D:status>
          </D:propstat>
       </D:response>
    </D:multistatus>


7.1.2 Example: PROPFIND by non-bind-aware client

    In this example, the client isn't aware of the 208 status code
    introduced by this specification.  As the "Depth: infinity" PROPFIND
    request would cause a loop condition, the whole request is rejected
    with a 506 status.

    >> Request:

    PROPFIND /Coll/ HTTP/1.1
    Host: www.example.com
    Depth: infinity
    Content-Type: text/xml; charset="utf-8"
    Content-Length: xxx

    <?xml version="1.0" encoding="utf-8" ?>
    <D:propfind xmlns:D="DAV:">
       <D:prop> <D:displayname/> </D:prop>
    </D:propfind>

    >> Response:

    HTTP/1.1 506 Loop Detected


7.2 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.





-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Saturday, 6 March 2004 15:12:21 UTC