W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2006

[Bug 220] Do status codes belong into pre/postcondition definitions?

From: <bugzilla@soe.ucsc.edu>
Date: Sun, 22 Jan 2006 02:19:44 -0800
Message-Id: <200601221019.k0MAJiVh013600@ietf.cse.ucsc.edu>
To: w3c-dist-auth@w3.org

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=220

julian.reschke@greenbytes.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|julian.reschke@greenbytes.de|elias@cse.ucsc.edu



------- Additional Comments From julian.reschke@greenbytes.de  2006-01-22 02:19 -------
Proposed changes in
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.issue.bz220>
and below:


Section 15., para. 13:
OLD:

    Use with: 400 Bad Request
 
    Purpose: (precondition) -- A request may include a Lock-Token header
       to identify a lock for the purposes of an operation such as
       refresh LOCK or UNLOCK.  However, if the Request-URI doe not fall
       within the scope of the lock identified by the token, the server
       SHOULD use this error.  The lock may have a scope that does not
       include the Request-URI, or the lock could have disappeared, or
       the token may be invalid.

NEW:

    Purpose: (precondition) -- A request may include a Lock-Token header
       to identify a lock for the purposes of an operation such as
       refresh LOCK or UNLOCK.  However, if the Request-URI doe not fall
       within the scope of the lock identified by the token, the server
       SHOULD use this error.  The lock may have a scope that does not
       include the Request-URI, or the lock could have disappeared, or
       the token may be invalid.


Section 15., para. 16:
OLD:

    Use with: 4xx responses, e.g. 400 Bad Request or 423 Locked
 
    Purpose: The request could not succeed because a lock token should
       have been submitted.  This element, if present, MUST contain at
       least one URL of a locked resource that prevented the request.  In
       cases of MOVE, COPY and DELETE where collection locks are
       involved, it can be difficult for the client to find out which
       locked resource made the request fail -- but the server is only
       resonsible for returning one such locked resource.  The server MAY
       return every locked resource that prevented the request from
       succeeding if it knows them all.

NEW:

    Purpose: The request could not succeed because a lock token should
       have been submitted.  This element, if present, MUST contain at
       least one URL of a locked resource that prevented the request.  In
       cases of MOVE, COPY and DELETE where collection locks are
       involved, it can be difficult for the client to find out which
       locked resource made the request fail -- but the server is only
       resonsible for returning one such locked resource.  The server MAY
       return every locked resource that prevented the request from
       succeeding if it knows them all.


Section 15., para. 18:
OLD:

    Use with: Typically 423 Locked
 
    Purpose: A LOCK request failed due the presence of an already
       existing conflicting lock.  Note that a lock can be in conflict
       although the resource to which the request was directed is only
       indirectly locked.  In this case, the precondition code can be
       used to inform the client about the resource which is the root of
       the conflicting lock, avoiding a separate lookup of the
       "lockdiscovery" property.

NEW:

    Purpose: A LOCK request failed due the presence of an already
       existing conflicting lock.  Note that a lock can be in conflict
       although the resource to which the request was directed is only
       indirectly locked.  In this case, the precondition code can be
       used to inform the client about the resource which is the root of
       the conflicting lock, avoiding a separate lookup of the
       "lockdiscovery" property.


Section 15., para. 21:
OLD:

    Use with: 403 Forbidden
 
    Purpose: (precondition) -- If the server rejects a client request
       because the request body contains an external entity, the server
       SHOULD use this error.

NEW:

    Purpose: (precondition) -- If the server rejects a client request
       because the request body contains an external entity, the server
       SHOULD use this error.


Section 15., para. 24:
OLD:

    Use with: 409 Conflict
 
    Purpose: (postcondition) -- The server received an otherwise-valid
       MOVE or COPY request, but cannot maintain the live properties with
       the same behavior at the destination.  It may be that the server
       only supports some live properties in some parts of the
       repository, or simply has an internal error.

NEW:

    Purpose: (postcondition) -- The server received an otherwise-valid
       MOVE or COPY request, but cannot maintain the live properties with
       the same behavior at the destination.  It may be that the server
       only supports some live properties in some parts of the
       repository, or simply has an internal error.


Section 15., para. 27:
OLD:

    Use with: 403 Forbidden

    Purpose: (precondition) -- This server does not allow infinite-depth
       PROPFIND requests on collections.

NEW:

    Purpose: (precondition) -- This server does not allow infinite-depth
       PROPFIND requests on collections.


Section 15., para. 30:
OLD:

    Use with: 403 Forbidden
 
    Purpose: (precondition) -- The client attempted to set a read-only
       property in a PROPPATCH (such as DAV:getetag).

NEW:

    Purpose: (precondition) -- The client attempted to set a read-only
       property in a PROPPATCH (such as DAV:getetag).






------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
Received on Sunday, 22 January 2006 10:19:52 GMT

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