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

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

From: Clemm, Geoff <gclemm@rational.com>
Date: Thu, 1 Aug 2002 09:43:05 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B107A5D575@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org

   From: Julian Reschke [mailto:julian.reschke@greenbytes.de]

   > From: Nevermann, Dr.,Peter
   >
   > 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.

Yes, there is no order defined in any of the HTTP or WebDAV RFCs.
So if there are multiple reasons for failure, it just depends
on which check is done first by a given implementation.

   > Another issue, which we find difficult sometimes, is to decide
   > whether to use 403 or 409 as status code on DeltaV precondition
   > violations.

There is no rigorous way to decide which of these to return.  The
heuristic I use is that if there is some operation I can do to the
current resource associated with that URL that would (or might) make
that request succeed, then I'd return a 409, while if I'd have to
associate a different resource (or no resource) with the URL to get
the request to work, I'd return a 403.

   > 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.

I wouldn't use a 409 here because it is not a conflict with the
"current" state of the resource, because I don't consider "not
existing" to be a state of the resource.  This is related to my position
that the "identity" of a resource is not determined by its URI, since
that would not allow you to say "two URI are being mapped to the same
resource" (something that RFC2616 explicitly says is allowed).

But this is definitely a judgement call, so I think it reasonable
for an implementation to return either 403 or 409 in this case.

   > 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...

I agree.

   > (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.

I agree.

Cheers,
Geoff
Received on Thursday, 1 August 2002 09:43:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:43 GMT