W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

REDIRECTREF issue "8.1_deep_lock_complexity", was: WGLC draft-ietf-webdav-redirectref-protocol-12

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 01 Oct 2005 21:40:37 +0200
Message-ID: <433EE635.5040708@gmx.de>
To: webdav <w3c-dist-auth@w3.org>
CC: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, John Baumgarten <jbaumgarten@apple.com>

Geoffrey M Clemm wrote:
> 
> I agree with Julian that the Depth infinity section of redirectref should
> be redefined based on this implementation experience.
> 
> Cheers,
> Geoff

OK, I finally got around reviewing the issue. I have changed the spec 
based on the principle of "least client astonishment", letting the 
behaviour default to "the right thing". That is, non redirect-aware 
clients will see no difference when applying LOCK, COPY, MOVE or DELETE 
to a collection that may contain redirects. (Our server currently obeys 
the Apply-To-Redirect-Ref header for COPY and MOVE, but I'm not aware of 
any use case depending on that, so I'll simply change the behaviour).

Not surprisingly, the spec has gotten quiet a bit shorter because of that.

Feedback appreciated -- I'd like to submit this as a revised draft 
addressing all WGLC comments before the cutoff date for the upcoming IETF.

Best regards, Julian

--

Link to issue for tracking: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-issues.html#8.1_deep_lock_complexity>

Link to latest edits (includes change tracking): 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-latest.html>

Revised spec text (Section 8):

8.  Operations on Collections That Contain Redirect Reference Resources

    According to [RFC2518], Section 9.2, methods that have defined
    interactions with the "Depth" request header should apply all other
    request headers to each resource in scope.  However, applying this
    principle to the "Apply-To-Redirect-Ref" header uniformly would make
    it impractical to implement this specification on top of existing
    servers and also would result in unexpected server behaviour for
    clients that do not take the existence of redirect references into
    account.  On the other hand, the definition of the "Depth" header
    allows to explicitly define alternate behaviours.

    For this reason, this specification defines the interaction between
    "Depth" and "Apply-To-Redirect-Ref" request headers on a case-by-case
    basis, and also provides a default for methods not mentioned here
    that do not specify the behaviour themselves.

     +-------------+-----------------+------------------+-----------+
     | method name | defined in      | supported depths | behaviour |
     +-------------+-----------------+------------------+-----------+
     | COPY        | [RFC2518], 8.9  | 0, infinity      | "T"       |
     | DELETE      | [RFC2518], 8.7  | infinity         | "T"       |
     | LOCK        | [RFC2518], 8.11 | 0, infinity      | "T"       |
     | MOVE        | [RFC2518], 8.10 | 0, infinity      | "T"       |
     | PROPFIND    | [RFC2518], 8.2  | 0, 1, infinity   | inherit   |
     | REPORT      | [RFC3253], 3.6  | 0, 1, infinity   | inherit   |
     | default     |                 |                  | "T"       |
     +-------------+-----------------+------------------+-----------+

    When the behaviour is defined to be "inherit", the method should
    follow RFC2518's default behaviour for "Depth" operations, which
    means applying the value given for "Apply-To-Redirect-Ref" to each
    resource in scope.  On the other hand, when it is defined to be "T",
    the method should behave as if a "Apply-To-Redirect-Ref: T" header
    was specified for each operation on child resources.  The latter
    ensures that "Depth: infinity" operations will not fail unexpectedly
    just because there was a redirect reference resource in scope.

8.1  Example: PROPFIND on a Collection with Redirect Reference Resources

    Suppose a PROPFIND request with Depth: infinity is submitted to the
    following collection, with the members shown here:

    /MyCollection/
         (non-reference resource) diary.html
         (redirect reference resource) nunavut

    >> Request:

    PROPFIND /MyCollection/ HTTP/1.1
    Host: example.com
    Depth: infinity
    Apply-To-Redirect-Ref: F
    Content-Type: text/xml
    Content-Length: xxxx

    <?xml version="1.0" ?>
    <D:propfind xmlns:D="DAV: ">
      <D:prop xmlns:J="http://example.com/jsprops/">
        <D:resourcetype/>
        <J:keywords/>
      </D:prop>
    </D:propfind>

    >> Response:

    HTTP/1.1 207 Multi-Status
    Content-Type: text/xml
    Content-Length: xxxx

    <?xml version="1.0" ?>
    <D:multistatus xmlns:D="DAV:" xmlns:J="http://example.com/jsprops/">
      <D:response>
        <D:href>/MyCollection/</D:href>
        <D:propstat>
          <D:prop>
            <D:resourcetype><D:collection/></D:resourcetype>
            <J:keywords>diary, interests, hobbies</J:keywords>
          </D:prop>
          <D:status>HTTP/1.1 200 OK</D:status>
        </D:propstat>
      </D:response>
      <D:response>
        <D:href>/MyCollection/diary.html</D:href>
        <D:propstat>
          <D:prop>
            <D:resourcetype/>
            <J:keywords>diary, travel, family, history</J:keywords>
          </D:prop>
          <D:status>HTTP/1.1 200 OK</D:status>
        </D:propstat>
      </D:response>
      <D:response>
        <D:href>/MyCollection/nunavut</D:href>
        <D:status>HTTP/1.1 302 Found</D:status>
        <D:location>
          <D:href>http://example.ca/art/inuit/</D:href>
        </D:location>
      </D:response>
    </D:multistatus>

    In this example the Depth header is set to infinity, and the Apply-
    To-Redirect-Ref header is set to "F".  The collection contains one
    URI that identifies a redirect reference resource.  The response
    element for the redirect reference resource has a status of 302
    (Found), and includes a DAV:location extension element to allow
    clients to retrieve the properties of its target resource.  (The
    response element for the redirect reference resource does not include
    the requested properties.  The client can submit another PROPFIND
    request to the URI in the DAV:location pseudo-property to retrieve
    those properties.)

8.2  Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with
      Redirect Reference Resources

    Suppose a PROPFIND request with "Apply-To-Redirect-Ref: T" and Depth:
    infinity is submitted to the following collection, with the members
    shown here:

    /MyCollection/
         (non-reference resource) diary.html
         (redirect reference resource) nunavut

    >> Request:

    PROPFIND /MyCollection/ HTTP/1.1
    Host: example.com
    Depth: infinity
    Apply-To-Redirect-Ref: T
    Content-Type: text/xml
    Content-Length: xxxx

    <?xml version="1.0" ?>
    <D:propfind xmlns:D="DAV:">
      <D:prop>
        <D:resourcetype/>
        <D:reftarget/>
        <D:redirect-lifetime/>
      </D:prop>
    </D:propfind>

    >> Response:

    HTTP/1.1 207 Multi-Status
    Content-Type: text/xml
    Content-Length: xxxx

    <?xml version="1.0" ?>
    <D:multistatus xmlns:D="DAV:">
      <D:response>
        <D:href>/MyCollection/</D:href>
        <D:propstat>
          <D:prop>
            <D:resourcetype><D:collection/></D:resourcetype>
          </D:prop>
          <D:status>HTTP/1.1 200 OK</D:status>
        </D:propstat>
        <D:propstat>
          <D:prop>
            <D:reftarget/>
            <D:redirect-lifetime/>
          </D:prop>
          <D:status>HTTP/1.1 404 Not Found</D:status>
        </D:propstat>
      </D:response>
      <D:response>
        <D:href>/MyCollection/diary.html</D:href>
        <D:propstat>
          <D:prop>
            <D:resourcetype/>
          </D:prop>
          <D:status>HTTP/1.1 200 OK</D:status>
        </D:propstat>
        <D:propstat>
          <D:prop>
            <D:reftarget/>
            <D:redirect-lifetime/>
          </D:prop>
          <D:status>HTTP/1.1 404 Not Found</D:status>
        </D:propstat>
      </D:response>
      <D:response>
        <D:href>/MyCollection/nunavut</D:href>
        <D:propstat>
          <D:prop>
            <D:resourcetype><D:redirectref/></D:resourcetype>
            <D:reftarget>
              <D:href>http://example.ca/art/inuit/</D:href>
            </D:reftarget>
            <D:redirect-lifetime><D:temporary/></D:redirect-lifetime>
          </D:prop>
        <D:status>HTTP/1.1 200 OK</D:status>
        </D:propstat>
      </D:response>
    </D:multistatus>

    Since the "Apply-To-Redirect-Ref: T" header is present, the response
    shows the properties of the redirect reference resource in the
    collection rather than reporting a 302 status.
Received on Saturday, 1 October 2005 19:41:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:10 GMT