- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Sat, 18 Nov 2000 09:37:24 -0500 (EST)
- To: ietf-dav-versioning@w3.org
I agree that this list is useful information, but since it can be derived from the semantics defined in the protocol, I see it more as commentary, rather than as something that should appear in the protocol definition. Note that since a server might not support all actions that are allowed by the protocol, the two categories are: errors that are always 403's, and errors that are either 403's or 409's, depending on the server. Cheers, Geoff From: Tim_Ellison@uk.ibm.com 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 Saturday, 18 November 2000 09:38:07 UTC