[Bug 196] New: LOCK_ISSUES_ERROR_CODES

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

           Summary: LOCK_ISSUES_ERROR_CODES
           Product: WebDAV-RFC2518-bis
           Version: -08
          Platform: Other
               URL: http://lists.w3.org/Archives/Public/w3c-dist-
                    auth/1999AprJun/0246.html
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: 08.  HTTP Methods for Distributed Authoring
        AssignedTo: joe-bugzilla@cursive.net
        ReportedBy: julian.reschke@greenbytes.de
         QAContact: w3c-dist-auth@w3.org


Reported by Jason Crawford in
<http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0246.html>:

Upon cursory reading of the rfc 2518 sec 8.10.4 through 8.11 I was confused by
the plethoria of error codes. Nothing seems to unify them. 
8.10.4 speaks of a return code of 409 Conflict if a lock can't be granted. 
- Firstly, I can't tell if it is saying that the 409 is within the multistatus
body... or in the response header. 
- Secondly, later text seems to use a different status codes and never mentions
this one again. 
8.10.7 lists status codes 
- 200 OK, 412 Precondition Failed, and 423 Locked are listed, but 409 Conflict
(mentioned above) is not. 
- In the case of 412 Precondition Failed, the description the follows doesn't
seem to describe a "precondition failed". And it sounds like it's talking about
an access request that includes a "locktoken", not a LOCK request that generates
one. 
- The 423 Locked condition also sort of sounds like it's talking about an access
request rather than a LOCK request. 
8.10.10 lists LOCK status codes 
- 207 Multistatus which was not mentioned above 
- 403 Forbidden which was not mentioned above. 
- 424 Failed dependency which was not mentioned above. 
8.11 UNLOCK 
- we don't mention what the failure response should look like. 
- comment: 200 OK seems like a better response than 204 No Content. The brief
explanation isn't persuasive and seems to say that the response code should
serve the purpose of the Content-Length. header. 
- we should probably explicitly say if an UNLOCK can only be done on the
original resource... and will fail even if the resource specified is locked by
virtue of being a child of the original resource. Or is this too obvious? I know
it's something easy to goof up in an implementation.



------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

Received on Monday, 21 November 2005 17:31:17 UTC