RE: DeltaV methods on locked non-VCR: which response code?

> From: [email protected]
> [mailto:[email protected]]On Behalf Of Nevermann, Dr.,
> Peter
> Sent: Thursday, August 01, 2002 10:21 AM
> To: '[email protected]'
> Subject: RE: DeltaV methods on locked non-VCR: which response code?
>
>
>
> Thanks, Geoff!
>
> Some of us were assuming that checking for the lock ("as being
> WebDAV") had
> priority over checking of DeltaV precondition violations ... in which case
> 423 would be the response in most of the cases below. But, as we
> can deduce
> from your response, that is not the case.

I'd say that this is higly implementation dependant, and I don't think that
RFC3253 mandates a specific oder in checking these conditions.

> Another issue, which we find difficult sometimes, is to decide whether to
> use 403 or 409 as status code on DeltaV precondition violations.
>
>
> Example 1: assume existing collection at /ws/bar then
>
> MKWORKSPACE /ws/bar
>
> returns 403 with DAV:resource-must-be-null ... as you stated below.
> According to section 1.6 of RFC 3253 this means that the request
> should not
> be repeated because it will always fail. But it could be 409
> because: isn't
> the user able to resolve the conflict by deleting /ws/bar and
> then resubmit
> the request?

HTTP says about 409:

"The request could not be completed due to a conflict with the current state
of the resource."

So I think I agree with you.

> Example 2: assume checked-in VCR at /foo.xml and
>
> CHECKOUT /foo.xml (without DAV:fork-ok)
>
> (a) violating precondition
> DAV:checkout-of-version-with-descendant-is-discouraged; then I
> would return
> status code 409 since the user can resolve the conflict by passing the
> DAV:fork-ok element.

But that would be a different request, right? So you didn't "fix" the state
of the resource, but the nature of your request...

> (b) violating precondition
> DAV:checkout-of-version-with-descendant-is-forbidden; then I would return
> status code 403 ... hm, or should it be 409 since the conflict could be
> resolved by proppatching the DAV:checkout-fork property???

I think so.