- From: Hall, Shaun <Shaun.Hall@gbr.xerox.com>
- Date: Fri, 15 Jun 2001 14:25:26 +0100
- To: "'Tim_Ellison@uk.ibm.com'" <Tim_Ellison@uk.ibm.com>, "'W3C WebDAV Mailing List'" <w3c-dist-auth@w3.org>
> -----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