W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2000

RE: PUT and Lock

From: Hall, Shaun <Shaun.Hall@gbr.xerox.com>
Date: Fri, 8 Dec 2000 15:09:03 -0000
Message-ID: <B99BE740B488D311B4AA00805FBB776750A705@gbrwgcms03.wgc.gbr.xerox.com>
To: "'Greg Stein'" <gstein@lyra.org>, w3c-dist-auth@w3.org
> -----Original Message-----
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: 08 December 2000 05:31
> To: w3c-dist-auth@w3.org
> 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
Received on Friday, 8 December 2000 10:13:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:55 GMT