RE: Status code for creating lock-null resource

At 11:00 PM -0400 6/27/01, Clemm, Geoff wrote:
>Dan has lots of good stuff in this message that I'll want to
>follow-up on, but I first wanted to focus on one particular
>comment:
>
>    From: Dan Brotsky [mailto:dbrotsky@Adobe.COM]
>
>    Geoff is suggesting something slightly different: that LOCK not
>    even be allowed on unmapped-URIs.  This also gets rid of LNRs and
>    has the advantage that you always know whether something is a
>    collection or not.  However it doesn't allow users to
>    simultaneously create and LOCK resources for further editing, which
>    bothers me.
>
>Could you expand on why this bothers you?

There are actually three reasons:

1. Because it sets you up for ambiguity and race conditions by 
breaking a single user-conceptual operation (beginning to edit a new 
resource) into two protocol operations (PUT and LOCK).  A client that 
wants to create and edit a new resource will go through a 
conventional sequence such as HEAD (to verify the URL as unmapped), 
PUT (to create the resource), and LOCK (to reserve the resource for 
editing).  This conflicts not only with itself but with the 
conventional sequence for editing an existing resource is LOCK / GET 
(LOCK first to make sure the GET content is the latest content). 
This gives rise to two canonical problem cases:

a. If I'm creating and editing a new resource, and you are editing a 
resource but specify my name by mistake, then my client has to deal 
with the unexpected (and meaningless at the user level) case where I 
successfully create the resource but then can't edit it, and your 
client has to deal with the unexpected (and meaningless at the user 
level) case where you open a resource to edit it only to find that 
it's empty or doesn't contain anything like what I was expecting.

b. If we're both trying to create and edit the same (new) resource, 
and my PUT precedes yours but my LOCK follows yours, then once I've 
obtained the LOCK I find that the etag on the resource is different 
than the one I got back from my PUT.  This is the canonical 
client-side warning sign that I'm in a race with someone else, and I 
have to stop and make sure that I pull down the current content.  At 
that point, unless you and I were using the same "template" resource 
in our initial PUTs, I've got a real problem.  I either have to blow 
away your edit (which I'm not entitled to do under normal 
circumstances) or I need to give up my lock.  But by then your LOCK 
has failed, so you've figured out that someone else is creating the 
resource and you've given up.

(I have observed both of these scenarios in existing graphic arts 
workflows, by the way.  There are many workflow systems in use that 
have exactly this kind of problem.)

2. Because there's no well-defined way for PUT to reliably create a 
no-content resource, which is the kind I claim you want to be 
creating when you're creating a new one but don't have content for it 
yet.  Most servers given a PUT of 0 length create a 0-length 
resource, which is quite a different thing than a no-content one.

3. Because doing a PUT and then a LOCK and then (eventually) another 
PUT forces you to make *two* updates to the resource rather than one, 
and the controlling server may not actually want to authorize that. 
(For example, workflow servers often want to send things off for 
approval, etc., each time they are updated.)

>   Since (I believe) this is
>the only thing that you gain with "unmapped URI locks" (UULs,
>previously known as LNRs :-), it is important to understand why (or
>whether) this matters enough to warrant the kind of confusion and
>complexity that UULs bring to the model.
>
>Suppose UULs are supported.  If you issue a LOCK against an unmapped
>URI, this may fail because someone already has a lock on that URI.  In
>this case, you either need to wait until that lock is removed (at
>which time, it is likely there is a resource mapped to that URI, but
>maybe not), or you need to try again on a different URI.

Don't get me wrong: I am as opposed to UULs as I am to LNRs!

>Now suppose UULs are not supported.  You can't issue a LOCK against an
>unmapped URI,

My proposal is that you *can* do this, but the effect is that a 
no-content resource is created and bound to that URI.

>  so instead, you first create a resource *of the
>appropriate type* and then try to LOCK that.

The big differences between this proposal and yours seem to be:

1. The initial content of the resource (none) is fixed.

2. The resource can be made a collection via MKCOL.

3. There's no chance of race conditions.

>   This LOCK request may
>fail because someone already has a lock on that URI.  In this case,
>you either need to wait until that lock is removed (at which time, it
>is likely there is a resource mapped to that URI, but maybe not), or
>you need to try again on a different URI.
>
>Those two cases look very similar (in fact, I copied the text
>of the first case into the second case, so they should look
>*really* similar :-).  So what do you really gain with UULs?

See above.  I think we're very close.

>Note: for compatibility with old 2518 servers, we shouldn't say that a
>LOCK MUST fail on an unmapped URI, but we certainly could amend the
>protocol to say that it SHOULD fail.  Since UULs act so differently on
>current servers, this is probably the only thing we could say, if we
>wanted to tell client writers how to achieve interoperability with
>existing servers.

In my proposal, there is no incompatibility with existing servers, 
because the LNR they create is a no-content resource (or would be, if 
you were allowed to do a GET :^), and you can still issue a MKCOL.

So let me ask you the converse question: You seem to be worried by 
the fact that we don't know what kind of resource (collection or not) 
the new resource is going to be.  What's the problem with letting the 
new resource start out as a no-content non-collection and then be 
made into a collection?

Note that in both of our proposals the same requests are 
made---either a PUT or a MKCOL and a LOCK.  It's just that in my 
version the LOCK comes first (a la the LOCK / GET sequence that 
initiates an edit).  And in my version the client doesn't have to 
figure out whether the resource exists before initiating the 
sequence: all edits (of both existing and new resources) start out 
with a LOCK / GET, and in the case of the create the LOCK comes back 
with a 201 which tells the client that the GET would return a 204 
(and thus there's no reason to issue it).

     dan
-- 
Daniel Brotsky, Adobe Systems
tel 408-536-4150, pager 877-704-4062
2-way pager email: <mailto:page-dbrotsky@adobe.com>

Received on Thursday, 28 June 2001 03:38:35 UTC