Subject: Re: edits on BIND draft

From: Julian Reschke <[email-masked]>
Date: Mon, 05 Jan 2004 18:25:58 +0100

Julian Reschke wrote:

> 
> On
> 
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html>:
> 
> - Add issues "ED_authors" and "ED_updates".
> - Add section about capability discovery (DAV header).
> - Close issue "5.1_LOOP_STATUS" (only use 208 status when client signals 
>  support for the BIND spec).

OK,

the only open issue that's left (not counting the missing plan how to 
handle locking) seems to be

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.ED_updates>

It seems that there was consensus to say that BIND does update RFC2518, 
while there's no consensus about the relationship to RFC3253. As this is 
a minor editorial question, I propose to just say "updated 2518" and to 
close the issue.

Julian

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

---

From: Julian Reschke <[email-masked]>
Date: Sun, 11 Jan 2004 13:01:57 +0100

Julian Reschke wrote:

On

    Add and close issues "9.2_redirect_loops", "ED_authors" and
    "ED_updates". Add section about capability discovery (DAV header).
    Close issues "5.1_LOOP_STATUS".

In particular, the explanation for status 208 has been rewritten stating 
that it will only occur for collections upon Depth: infinity, the 
example has been fixed (DAV header added) and another example for a 
non-BIND-aware client was added. In addition, in section 8 the 
description for the DAV *request* header has been expanded.

Feedback appreciated,

Julian

- TXT version of the updated sections -

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). Otherwise the entire
    PROPFIND request MUST fail with the 506 status described below.

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.

8. Capability discovery

8.1 OPTIONS method

    If the server supports bindings, it MUST return the compliance class
    name "bind" as a field in the "DAV" response header (see [RFC2518],
    section 9.1) from an OPTIONS request on any resource implemented by
    that server. A value of "bind" in the "DAV" header MUST indicate that
    the server supports all MUST level requirements and REQUIRED features
    specified in this document.

8.2 'DAV' request header

8.2.1 Generic syntax

    This specification introduces the 'DAV' request header that allows
    clients to signal compliance to specific WebDAV features. It has the
    same syntax as the response header defined in [RFC2518], section 9.1,
    but MAY be used with any method.

    Note that clients MUST NOT submit a specific compliance class name in
    the request header unless the specification defining this compliance
    class specifically defines it's semantics for clients.

    Note that if a server chooses to vary the result of a request based
    on values in the "DAV" header, the response either MUST NOT be
    cacheable or the server MUST mark the response accordingly using the
    "Vary" header (see [RFC2616], section 14.44).

8.2.2 Client compliance class 'bind'

    Clients SHOULD signal support for all MUST level requirements and
    REQUIRED features by submitting a "DAV" request header containing the
    compliance class name "bind".  In particular, the client MUST
    understand the 208 status code defined in Section 7.1.

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sun, 11 Jan 2004 19:44:42 -0500

I believe the previous wording of the 208 section
was better, and should be restored.

In particular, I don't see why status 208 should be
restricted to collections (if you have multiple bindings
to a non-collection, a server should be able to generate
208's for that as well).

Also, I don't see why it should be restricted to Depth:infinity
(it can arise for Depth:1).

The new sections on the DAV header are good.

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Mon, 12 Jan 2004 09:56:04 +0100

> was better, and should be restored.

Well, we found it to be confusing. Obviously neither is good enough, and 
we need to work on it :-)

> to a non-collection, a server should be able to generate

Why would it do that? It could generate a 200 as well.

The confusing thing (to us) was not entirely clear about what it means 
to be "already reported" and when it occur. The intent of the change was 
to clarify that.

> (it can arise for Depth:1).

Not the way it is defined now.

OK, before we discuss the wording, let's try to agree on what it should 
mean:

The intent of the 208 code was to allow PROPFIND to handle bind loops.

BIND loops are relevant only for Depth: Infinity operations (for Depth: 
0, no bindings are enumerated anyway, for Depth: 1, enumerating another 
binding to a previously reported collection is harmless).

Thus, to achieve this goal in the most simple way, I'd say that the 
current description is the best one:

A 208 is reported instead of a 200 whenever the server decides not to 
enumerate the children of a particular collection because they have 
already been reported. This situation (as discussed above) IMHO can only 
occur for Depth: infinity.

> The new sections on the DAV header are good.

Thanks,

Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 12 Jan 2004 11:01:08 +0100

Hi,

when thinking about actually *implementing* this stuff, I discovered 
another issue here.

Take a server that allows Depth: infinity upon PROPFIND.  In general, 
the only way to implement this efficiently is to *stream* the 
multistatus response.  However this means that the server needs to 
decide about the HTTP status code to return *prior* to actually doing 
the recursion.  Therefore, requiring the server to return a 506 status 
in case there's a bind loop somewhere below the request URI will not work.

An obvious alternative would be to allow the 506 to be returned inside 
the DAV:status element for the resource the server refuses to recurse 
into.  Of course that would mean that the client essentially would get a 
partly incorrect picture of the server state.  However, I don't think 
there's any way to avoid that (except for rejecting all Depth: infinity 
PROPFINDs, like many servers already do).

Julian