- From: <bugzilla@soe.ucsc.edu>
- Date: Fri, 6 Jan 2006 10:36:53 -0800
- To: w3c-dist-auth@w3.org
http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=196
julian.reschke@greenbytes.de changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|julian.reschke@greenbytes.de|elias@cse.ucsc.edu
Status|ASSIGNED |NEW
Version|-08 |-10
------- Additional Comments From julian.reschke@greenbytes.de 2006-01-06 10:36 -------
Discussed during 2006-01-06 conference call. Recommendation to close as fixed;
re-assigning to Elias.
In particular:
"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."
The spec nows says it's a multistatus (207).
"- Secondly, later text seems to use a different status codes and never mentions
this one again."
If this was about the example in 8.10.10, this is now consistent.
"8.10.7 lists status codes
- 200 OK, 412 Precondition Failed, and 423 Locked are listed, but 409 Conflict
(mentioned above) is not."
409 as discussed doesn't occur anymore, but the new spec mentions another case
where you can get 409. 412 will not occur because LOCK refresh doesn't use the
If header anymore.
"- 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."
See above.
"- The 423 Locked condition also sort of sounds like it's talking about an
access request rather than a LOCK request."
We're in the section about the LOCK request here, so that doesn't seem to be a
problem.
"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. "
207 is now mentioned, the other codes appear *inside* the multistatus, and the
spec doesn't mention any specific status codes for use inside the body anyway.
"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."
Failure codes are now mentioned. The issue of 200 vs 204 seems to be irrelevant
in respect to interop (not aware of any problems), so recommended not to change.
- 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."
Spec has been changed that any resource in scope of the lock can be used.
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
Received on Friday, 6 January 2006 18:36:58 UTC