Subject: RE: PUT and Lock

From: "Hall, Shaun" <[email-masked]>
Date: Fri, 8 Dec 2000 15:09:03 -0000

> -----Original Message-----
> From: Greg Stein [mailto:[email-masked]]
> Sent: 08 December 2000 05:31
> To: [email-masked]
> Subject: Re: PUT and Lock
> 

[snipped]

> Nope.
> 
> An If: header is a *pre* condition. The resource does not 
> exist until after
> the PUT method completes.

Agreed.

> A precondition with a no-tag-list 
> refers to all
> URIs involved in the operation. In this case: the Request-URI 
> and the parent
> collection. The no-tag-list is asserting a lock token on 
> *both* resources,
> the but the Request-URI does not have any locks associated 
> with it (it is a
> null resource).

Err where does it state that a no-tag-list refers to all URIs involved in
the operation?

Section 7.6 "...the If header for all locked resources that a method may
interact with or the method MUST fail."

Well, the null-resource isn't locked, so this statement doesn't apply.

Section 9.4.1 No-tag-list states "If a method, due to the presence of a
Depth or Destination header is applied to multiple resources, then the
no-tag-list MUST be applied to each resource ...".

We don't need Depth or Destination headers with a PUT. So how do you
conclude that all URIs are involved?

I interpreted (IMHO) the no-tag-list to be applied to just the parent in
this scenario.

Perhaps 9.4.1. should state "...MUST be applied to each non-null resource"?

The IF header is meant to have similar functionality as the If-Match header,
which RFC2616 states "is to allow effecient updates" and "prevent
inadvertent modification of the wrong version of a resource". Well since the
PUT is being attempted on a null-resource, it can't be the wrong version and
the user obviously wants to udpate the null-resource, therefore "effecient
update" should be interpreted as "I cannot be effecient because it ain't
there, so go ahead".

As you've guessed, I interpreted it to be Kevin's Choice #1 (201).

PS Greg, do you return 412 for other operations that can also be performed
in this PUT-like scenario on a null-resource i.e. MKCOL and LOCK (LNR) ?

[snipped]

> 
> Cheers,
> -g
> 
> -- 
> Greg Stein, http://www.lyra.org/
> 

Regards

Shaun Hall
Xerox Europe

---

From: Greg Stein <[email-masked]>
Date: Fri, 8 Dec 2000 18:55:05 -0800

On Fri, Dec 08, 2000 at 03:09:03PM -0000, Hall, Shaun wrote:
> Greg Stein wrote:
>...

You took that out of context. The statement indicates that you must supply
locktokens "in the If header ...". The statement does not indicate what the
If: header *applies* to.

> conclude that all URIs are involved?

I consider the spec to be deficient. You didn't quite quote it properly, and
the commas and complete sentence are important:

  "If a method, due to the presence of a Depth or Destination header, is
   applied to multiple resources then the no-tag-list MUST be applied to
   each resource the method is applied to."

I read "..., due to the presence of a Depth or Destination header, ..." as
an appositive. It is suggesting a way that multiple resources are involved,
but I do not view it as the canonical/complete list. For example, a MOVE
applies to a whole tree of resources, even when a Depth: header is not
present.

Second, the last phrase "... each resource the method is applied to." While
the "null resource" is not truly a resource, so it makes the above phrase a
bit confusing to tell whether it applies or not (e.g. it isn't a valid
resource, so it doesn't apply; or a null resource is a *type* of resource,
so it does apply), I consider that the PUT method *does* apply to the null
resource in question.

> I interpreted (IMHO) the no-tag-list to be applied to just the parent in

To use your argument ... where does it say it must be applied to the parent?
hehe :-)

If you submit a request with an If: header, then I've got to believe that it
applies to the resource (or lack thereof) identified by the Request-URI.

[ the parent thing does come up in S7.5, actually; it just isn't stated or
  clarified in the If: header description ]

> Perhaps 9.4.1. should state "...MUST be applied to each non-null resource"?

Or the spec should state "null resources have no associated locks." I tend
to believe this statement (it *is* "null" after all!), and this is why a
no-tag-list fails against a null resource in mod_dav.

I think it would be a mistake to change the phrasing to refer only to
non-null resources. Consider the case where I issue a PUT to an existing
resource, and I use the If: header to assert an etag on that resource, using
the no-tag-list format. But! Somebody has gone and deleted the resource. I
want my PUT to fail because the If: gets applied, and the etag assertion
fails. (under the premise that a null resource has no locks and no etags)

We could restate the above problem using a shared lock on the resource (not
the parent), and I assert a shared lock token via a no-tag-list. I want the
PUT to fail because the asserted lock token no longer exists.

[ note that it would fail for two reasons: the no-tag-list would apply to
  the parent on a PUT to a null resource and the parent doesn't have that
  locktoken, and it would fail on the null resource because it, too, does
  not have the lock token ]

> update" should be interpreted as "I cannot be effecient because it ain't

The last paragrph of RFC2616, S14.25 implies that the If-Match header
applies to the resource identified by the Request-URI. I would expect the
If: header to also apply to the resource identified by the Request-URI.

> As you've guessed, I interpreted it to be Kevin's Choice #1 (201).

Yup :-) ... and all in-between-the-lines reading of the exact choice of
words in RFC 2518 is beside the point, in my mind. I simply feel that the
intuitive operation of a no-tag-list in the If: header should apply to the
(possibly null) resource identified by the Request-URI.

IMO, there should be a clarification somewhere that a null resource has no
etags and no locks. That has a particular meaning/influence/purpose when
using If: headers and operations that affect more than the resource
identified by the Request-URI.

> in this PUT-like scenario on a null-resource i.e. MKCOL and LOCK (LNR) ?

For a null resource, the If: header must match the resource *and* its
parent. For a locknull resource, the If: header must match the resource
only. Operations on the locknull resource don't check the parent because
that was checked when the locknull was created (the creation modified the
parent, but the later operation has no further effect on the parent).

My suggestion for a PUT/MKCOL/LOCK against a null resource with a lock
parent is to use a tagged-list specifying the parent and its locktoken.

Cheers,
-g

---

From: "Kevin Wiggen" <[email-masked]>
Date: Tue, 26 Dec 2000 13:52:17 -0800

I will start this off by stating that I think some resolution needs to be
made on this issue.  We have interoperability problems :)  I will pledge to
change Xythos if that is consensus of the group.

I find I can agree with Greg and his comments.

However I don't like the idea of every URI being a null resource.  The
namespace does not exist and thus no IF header check can occur, as its not a
resource!!!  Therefore a PUT to a non existent resource with a no-tag list
in the IF header will only apply to the parent of the new resource.

I would like to hear what others think on this subject so we can make the
spec more clear one way or the other.  So far, I have only heard Greg
arguing for his interpretation, but I am sure others have opinions.

Kevin

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Greg Stein
Sent: Friday, December 08, 2000 6:55 PM
To: [email-masked]
Subject: Re: PUT and Lock

Cheers,
-g

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Thu, 28 Dec 2000 23:22:17 -0500 (EST)

At the heart of this debate seems to be the question of
whether or not a null resource "exists" when the If
pre-condition check is being made.

Suppose we consider that the null resource does exist.
Then I would argue that it would fall under the depth
lock of its parent, and therefore it is locked and
the PUT should succeed.  (Note that a locked null
resource is not the same as a "lock-null" resource,
since a "lock-null" resource is null resource that has
been explicitly locked by a LOCK being directly applied
to the null resource).

Suppose we consider that the null resource does not
exist.  Then it would not fall under the depth lock,
but then I would argue that it also should not be considered
during If processing, and again, the PUT should succeed.

So I agree with Kevin, JimW, and JimA that the 201
response is correct, and not the 412.

The only way the 412 would work is to say that the null
resource does not exist for the purposes of being locked
but the depth lock of its parent,
but does exist for the purposes of precondition checking,
which doesn't make sense to me.

Cheers,
Geoff

   From: "Kevin Wiggen" <[email-masked]>

   Kevin

   -----Original Message-----
   From: [email-masked]
   [mailto:[email-masked]]On Behalf Of Greg Stein
   Sent: Friday, December 08, 2000 6:55 PM
   To: [email-masked]
   Subject: Re: PUT and Lock

   Cheers,
   -g