W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > July to September 2001

RE: Postconditions with no XML elements defined?

From: Tim Ellison <tim@peir.com>
Date: Wed, 11 Jul 2001 21:44:38 +0100
To: "DeltaV" <ietf-dav-versioning@w3.org>

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: 11 July 2001 17:34
> To: Tim Ellison; ietf-dav-versioning@w3.org
> Subject: RE: Postconditions with no XML elements defined?
> Please make it simple and normative!

A simple list would suffice, right?

> > The preconditions are statements that must be true for a method to
> succeed,
> Sounds like if the precondition is not true the operation is "Forbidden",
> > and the postconditions are statements that must be true
> immediately after
> the method has suceeded.
> Sounds like there must be a "Conflict" if the postcondition cannot be met.
> If there are no strong objections, I propose that we adopt the simple
> normative rule a precondition is returned with 403 and a postcondition is
> returned with 409.

The 403 Forbidden means that you shouldn't bother trying any variations on
this request because they will fail, an example would be trying to MOVE a
version resource, there is nothing a client can do to make the server happy
about this.
A 409 Conflict means the client likely can do something to fix the resource
or server state so that the request will succeed, for example trying to
CHECKOUT a checked-out resource will fail, but can succeed if the resource
is first checked-in.

I don't think it is as simple as saying all preconditions are 403 and all
postconditions are 409 as it would lead to some anomolies, such as the
DAV:preserve-versioning-properties postcondition being a 409!

... but I did say that I wouldn't argue<g>

Received on Wednesday, 11 July 2001 16:44:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC