403&409 status codes

Section 7.1 of the spec describes how the server must answer a response
body for 403 & 409 responses with each method precondition that fails.

It seems to be an art to divide the preconditions between 403 and 409, but
seems like something we should agree upon.  There is usually some
combination of requests that the client can do to make a failing request
subsequently succeed.

My rule of thumb was "assume it is a 409 unless the client cannot fix the
situation without destroying resources".  For example, a client could make
one-version-selector-per-history-per-workspace succeed by deleting the
other version selector, but they can never make cannot-copy-history
succeed.

The sections where the preconditions appear in versioning-10.4 are in
parentheses after the name below.

403 Forbidden.
     The server understood the request, but is refusing to fulfill it.
     Authorization will not help and the request SHOULD NOT be repeated.
baseline-control-must-be-empty (16.4)
cannot-copy-history (15.7)
cannot-modify-protected-property (7.4)
cannot-modify-unsupported-property (7.4)
cannot-modify-version-content (7.3)
cannot-modify-version-property (7.4)
cannot-rename-resource (7.7, 15.8)
checkin-fork-forbidden (15.11)
checkout-of-checked-out-version-is-forbidden (15.10)
checkout-of-version-with-descendant-is-forbidden (15.10)
linear-activity (15.10, 15.11)
merge-destination-must-be-valid (16.5)
must-be-baseline (16.4)
must-be-collection (16.4)
must-be-checked-in-version-selector (9.5)
must-be-checked-out-version-selector (9.4)
must-be-version-or-version-selector (9.2, 16.1)
must-be-version-selector (15.10)
must-be-versionable (9.1)
must-have-no-members (16.4)
must-select-version (9.5, 15.2, 15.4, 15.7, 15.10, 15.12, 16.1, 16.5)
no-checkout-of-baseline-version (15.10)
no-unreserved-checkout-for-reserved-activity (15.10)
predecessor-in-checked-out-version-history (15.11)


409 Conflict
     The request could not be completed due to a conflict with the current
     state of the resource. This code is only allowed in situations where
     it is expected that the user might be able to resolve the conflict
     and resubmit the request.
cannot-add-to-existing-history (9.1)
cannot-merge-checked-out-resource (16.5)
cannot-modify-destination-parent-version-selector (15.8)
cannot-modify-version-selector-content (7.3)
cannot-modify-parent-version-selector (15.5, 15.8, 15.9)
cannot-modify-version-selector-property (7.4)
checkin-fork-discouraged (15.11)
checkin-requires-lock-token (9.3)
checkout-of-checked-out-version-is-discouraged (15.10)
checkout-of-version-with-descendant-is-discouraged (15.10)
checkout-required (16.5)
checkout-requires-lock-token (9.2)
initial-version-required (9.1)
label-must-exist (16.1)
merge-must-be-complete (15.11)
merge-requires-lock-token (16.5)
must-be-new-label (16.1)
must-be-version (9.1)
must-be-checked-out (9.3)
must-not-be-checked-out (9.2, 16.1)
no-checked-out-baselined-collection-members (15.11)
no-eclipsed-baselined-collection-members (15.11)
one-baseline-selector-per-history-per-workspace (16.4)
one-version-selector-per-history-per-workspace (15.9)
one-checkout-per-activity-per-history (15.10)
only-overwrite-mutable-version (15.11)
resource-must-be-null (16.2, 16.3)
set-target-requires-lock-token (9.5)
uncheckout-requires-lock-token (9.4)


Tim Ellison
Java Technology Centre, MP146
IBM UK Laboratory, Hursley Park, Winchester, UK.
tel: +44 (0)1962 819872  internal: 249872  MOBx: 270452

Received on Tuesday, 14 November 2000 13:25:10 UTC