Subject: resolving REDIRECT issue lc-58-update

From: Julian Reschke <[email-masked]>
Date: Sat, 09 Oct 2004 21:28:50 +0200

(see 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-latest.html#rfc.issue.lc-58-update>)

Here's a proposal for the missing update method, feedback appreciated:

7.  UPDATEREDIRECTREF Method

    The UPDATEREDIRECTREF method requests the update of a redirect
    reference resource.

    If a UPDATEREDIRECTREF request fails, the server state preceding the
    request MUST be restored.

    Responses from a UPDATEREDIRECTREF request MUST NOT be cached, as
    UPDATEREDIRECTREF has non-safe semantics (see [RFC2616], section
    9.1).

    Marshalling:

       The request body MUST be a DAV:updateredirectref XML element.

       <!ELEMENT updateredirectref (reftarget?, redirect-lifetime?)>
       See Section 5 for a definition of DAV:reftarget and
       DAV:redirect-lifetime.

       If no DAV:reftarget element is specified, the server MUST NOT
       change the target of the redirect reference.

       If no DAV:redirect-lifetime element is specified, the server MUST
       NOT change the lifetime of the redirect reference.

       If a response body for a successful request is included, it MUST
       be a DAV:updateredirectref-response XML element.  Note that this
       document does not define any elements for the UPDATEREDIRECTREF
       response body, but the DAV:updateredirectref-response element is
       defined to ensure interoperability between future extensions that
       do define elements for the response body.

       <!ELEMENT updateredirectref-response ANY>

    Preconditions:

       (DAV:locked-update-allowed): if the resource is write-locked, then
       the appropriate token MUST be specified in an If request header.

       (DAV:must-be-redirectref): the resource identified by the
       request-URI must be a redirect reference resource as defined by
       this specification.

       (DAV:redirect-lifetime-supported): see Section 5.

       (DAV:redirect-lifetime-update-supported): servers MAY support
       changing the DAV:redirect-lifetime property; if they don't, this
       condition code can be used to signal failure.

    Postconditions:

       (DAV:redirectref-updated): the DAV:reftarget and
       DAV:redirect-lifetime properties of the redirect reference have
       been updated accordingly.

7.1  Example: Updating a Redirect Reference Resource with
     UPDATEREDIRECTREF

    >> Request:

    UPDATEREDIRECTREF /~whitehead/dav/spec08.ref HTTP/1.1
    Host: www.example.com
    Apply-To-Redirect-Ref: T
    Content-Type: text/xml; charset="utf-8"
    Content-Length: xxx

    <?xml version="1.0" encoding="utf-8" ?>
    <D:updateredirectref xmlns:D="DAV:">
      <D:reftarget>
        <D:href>/i-d/draft-webdav-protocol-08b.txt</D:href>
      </D:reftarget>
    </D:updateredirectref>

    >> Response:

    HTTP/1.1 200 OK

    This request has updated the redirect reference's DAV:reftarget
    property to "/i-d/draft-webdav-protocol-08b.txt", and has not changed
    the DAV:redirect-lifetime property value.  Note that the
    "Apply-To-Redirect-Ref" request header must be used, otherwise the
    request would result in a redirect (3xx) response status.

Best regards, Julian

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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 19 Oct 2004 19:47:34 +0200

> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-latest.html#rfc.issue.lc-58-update>) 

OK,

I did some more minor edits (mainly reshuffled sections so that 
MKREDIRECTREF and UDATEREDIRECTREF can come back-to-back). I haven't 
done a trial implementation of UPDATEREDIRECTREF yet though, so we may 
need some more minor clarifications at a later point.

The main issue that's left is the question how to treat old clients, 
summarized in 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-latest.html#rfc.issue.old_clients>. 
I think this should be left to another iteration of the draft, so unless 
somebody objects, I'll submit this draft so that we have an up-to-date 
version published before the cut-off-date next week.

Best regards, Julian