- From: Clemm, Geoff <gclemm@rational.com>
- Date: Mon, 24 Feb 2003 09:38:20 -0500
- To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
> From: Lisa Dusseault > Are we possibly making things confusing by introducing a > postcondition "code" like (DAV:ordering-type-set) for something that > MUST be done? It makes it seem like the server might choose not to set > the ordering type, create the collection anyway, and respond with 409 > containing <DAV:ordering-type-set/>. Whether or not a particular request may "partially succeed" is up to the definition of that request. Most RFC3253 methods are defined to be atomic, i.e. they either succeed or they have no effect on the server state. The reason that multiple postconditions are defined for an atomic operation is to allow the server to give the client a more precise idea about which of the semantics of the request could not be achieved (the client can then use this information to give the user a better error message). WRT to the specific example mentioned here, I agree that this issue should be addressed by the ordering protocol, by having it state whether the methods it is defining/extending are atomic, or whether they are allowed to partially succeed. I recommend that they be required to be atomic. > Wouldn't a total failure to do > some required behavior normally be defined as a 500 response? The difference between 4xx and 5xx is whether or not it is considered a "client error" (e.g. an operation was attempted on a resource that was not in an appropriate state for that operation to succeed) or a "server error" (e.g. something went wrong on the server such as running out of virtual memory). So whether or not this is a 4xx or 5xx depends on whether the method definition allows server state to be changed when the operation does not fully succeed. From: Julian Reschke [mailto:julian.reschke@gmx.de] Yes, and I think that's something that should be possibly fixed in RFC3253. Failure to meet a postcondition (after all preconditions were verified) always is a server bug and thus would belong into the 5xx range. The main question is: which spec should fix that? I'd really like to see RFC2518bis to pick up (and clarify) this kind of error typing (maybe in a way that makes it optional?). Minimally, I agree that RFC3253 should be extended to allow error tokens to be returned with any 4xx or 5xx response code. I'll add this to the issues list, and start a thread on the topic in the versioning mailing list. In particular, as Julian points out, this would allow the more appropriate 5xx response code to be returned when a postcondition is violated. As for whether RFC2518bis picks this up, it probably is only useful to do so if appropriate error tokens are defined. I believe this would not only improve interoperable error reporting for 2518, but would help address some of the vagueness that remains in 2518. Cheers, Geoff
Received on Monday, 24 February 2003 09:38:58 UTC