Re: edits on BIND draft

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

Julian wrote on 01/11/2004 07:01:57 AM:

> 
> Julian Reschke wrote:
> 
> 
> On
> 
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html>:
> 
>     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.
> 
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>

Received on Sunday, 11 January 2004 19:44:52 UTC