- From: Clemm, Geoff <gclemm@rational.com>
- Date: Fri, 9 Feb 2001 06:57:17 -0500
- To: ietf-dav-versioning@w3.org
The choice of whether to return a 403 or a 409 was deliberately left up to the server. This will commonly depend on what options are supported by the server. Even if the protocol today makes it likely that only one of these status codes is returned by a server, I would not want to state this in the protocol, to leave room for servers that end up being more constrained or less constrained by future extensions to the protocol. Is this OK with you Jim? I completely agree with Jim's point about IETF controlling the error namespace, and will make this addition to the protocol unless there are any objections. Cheers, Geoff -----Original Message----- From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] Sent: Friday, February 09, 2001 1:51 AM To: ietf-dav-versioning@w3.org Subject: Status reporting comments At present, the DeltaV specification leaves it up to implementors to determine whether to return a 403 or a 409 for precondition and postcondition errors. Since the specification doesn't provide explicit guidance on this topic, it seems likely that this will lead to different implementations making different decisions. Since these status codes do have slightly different semantics (one the client might want to resubmit (409), the other the client should not resubmit(403)), this is unfortunate, since it will lead clients to lump 403 and 409 together, presumably never attempting to resubmit since the resubmit semantics of 403/409 cannot be depended upon. One way to rectify this is to explicitly note which of the status codes should be returned next to the precondition/postcondition XML element name, when it is possible to determine that only one status code will ever apply. In cases where it could depend, both 403/409 could be indicated. Also, I think the specification should explicitly note that the IETF controls the namespace of error XML elements, and that implementations are NOT free to create these XML elements willy-nilly if they encounter error conditions not forseen by the specification. - Jim
Received on Friday, 9 February 2001 06:49:08 UTC