RE: Status code for creating lock-null resource

> -----Original Message-----
> From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com]
> Sent: 15 June 2001 12:04
> To: 'W3C WebDAV Mailing List'
> Subject: RE: Status code for creating lock-null resource
> 
> "Hall, Shaun" <Shaun.Hall@gbr.xerox.com> wrote:
> > 1) Obviously it would go against the definition in
> > RFC 2616 for 201 Created.
> > 2) You haven't actually created a resource. An LNR doesn't
> > physically exist, you've only reserved the "name". You have
> > created a lock, but that is not the same thing.
> 
> Arrgh, where did this idea that a resource must "physically 
> exist" come
> from??

I meant they have no entity body unlike "normal" resources. I realise
servers may use a file to internally represent an LNR.

> 
> In what sense does  
> http://foo.com/cgi-bin/quote?> myportfolio,yesterday  (or
> 
> whatever) 'physically exist'?
> 
> A 
> 201 Created response looks like the ideal response for the 
> creation of a
> lock-null resource.  I did not read anything in RFC2616 to 
> contradict that.
> 

[snipped]

Disagree with 201, you haven't created a resource in the normal sense. You
cannot do a GET on an LNR for example. RFC 2616 sec 10.2.2 states "... a new
resource being created". You haven't created a new resource per se, but
reserved a name. You have created a lock, which is state. Okay, somehow the
server has to "create and store" properties for the LNR, but there is no
actual "entity body" and never will be unless a PUT is performed.

> 
> Lock-null resources are generally bad and should have been 
> strangled at
> birth.

See point 4) below.

[snipped]

Let us remind ourselves about a few things here (in conjunction with null
resource emails):

1) Locking's purpose it to avoid conflict, the lost update problem etc (RFC
2518 sec 6).

2) A null resource MUST NOT appear as a member of its parent collection (RFC
2518 sec 3).

3) A null resource MUST respond with a 404 for ALL methods other than PUT,
MKCOL, OPTIONS and LOCK (RFC 2518 sec 3).

4) Lock null resources (LNRs) are there to reserve name (RFC2518 sec 7.4).
They are there so a client can reserve the name *before they create the
resource* (store the "entity"). Admittedly, a server may use a file to
represent the LNR, but thats an implementation detail. Since the name is
reserved, it avoids potential conflict when the entity is actually stored
e.g. with a PUT.

5) Methods performed on LNRs other than PUT, MKCOL, OPTIONS, PROPFIND, LOCK
and UNLOCK MUST respond with a 404 or 405 (RFC 2518 sec 7.4).

6) If you UNLOCK an LNR, the resource is returned to the null resource state
(RFC 2518 sec 7.4). This may mean a server actually deletes the "file" it
used to represent the LNR, but thats another implementation detail.

The client should assume nothing about how the server implements the
protocol, in these cases, null resources and LNRs.

A few people interpret 2) and 3) to mean that a null resource doesn't
physically exist, which IMHO is convenient. As far as the client is
concerned, a null resource doesn't exist as per 3), and an LNR doesn't exist
as per 5).

Regards

Shaun Hall
Xerox Europe

Received on Friday, 15 June 2001 09:52:50 UTC