RE: Status code for creating lock-null resource

At 9:36 AM -0700 6/28/01, Lisa Dusseault wrote:
><snip>
>
>So let's imagine we could transform lock-null resources into locked empty
>resources -- the only requirement on the server would now be that the server
>would allow the creation of an empty resource through use of the LOCK
>request.  With a locked empty resource, it's a regular resource, it appears
>in listings, and it doesn't magically go away if no PUT request is received
>before UNLOCK.  Would this help us out?

I claim yes.  That's exactly what I'm proposing, and where I think 
Tim and Jim got to in their discussion earlier on this thread.

>A locked empty resource as I described would solve the PUT-control problem,
>but not the MKCOL problem, unless the server were required to be able to
>support MKCOL on a locked empty resource.

Which I think is reasonable, but I'm likely to be in the minority about this.

>   So if I have write and
>permissions access to a repository where other users have write and
>permissions access, I could create a directory called "lisa" - and there's a
>risk that somebody else can change permissions before I have a chance to.
>The malicious user could lock me out of my own directory.  On the other
>hand, presumably the malicious user could create a directory called "lisa"
>in the first place and not have to worry about waiting for me to create it.

I really don't think malicious users are the problem.  It's 
accidental collisions that are the problem: you want to make 
directory "lisa" because it's your name at the same time someone else 
wants to make file "lisa" because it's a picture of her niece Lisa. 
Accidental collisions are rare but a real pain if the underlying 
protocol allows races.

>Some servers will solve this problem by assigning special permissions to the
>creator of a resource, however I don't think we can rely on this being
>always the case. There are certainly use cases for other permissions models.
>We would want to think about whether it's valid for a server to grant
>permissions permission on newly created resources to principals that did not
>either create the new resource, or own the parent resource.

It's valid for servers to do whatever is appropriate for the 
application.  This gets back to the other example I raised in my 
message: workflow servers typically want to attribute workflow intent 
to file operations, so two PUTS are quite different than one, and 
LOCK / PUT means something quite different than PUT / LOCK.

I think that, without requiring servers to support "placeholder" 
resources of some kind, it's going to be hard to avoid races around 
LOCKING and creation.  I think that's why LNRs were introduced in the 
first place.  I simply think that the notion of placeholder was too 
restrictive, and the notion of a "placeholder that vanishes" was just 
ill-conceived.  Since HTTP already supports the notion of 
"placeholders" well with no-content resources, I think we can simply 
say that LOCKing an unmapped URI puts a locked no-content resource 
there, and it stays there until someone either says "here's content" 
with PUT or "actually it's a collection" with MKCOL.  If they really 
made a mistake they can say DELETE.

     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 16:08:55 UTC