- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sun, 11 Jan 2004 13:01:57 +0100
- To: webdav <w3c-dist-auth@w3.org>
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 07:02:56 UTC