RE: Status code for creating lock-null resource

At 9:36 AM -0700 6/28/01, Lisa Dusseault wrote:
>  > 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
>
>I believe this can, and should, be solved with the consistent use of
>"If-None-Match: *" in the PUT request, whenever a client is trying to create
>a new resource.

Good point.  (And thanks, I had completely missed this "idiom."  Like 
you, I wonder if servers are good about supporting it.)

But in the workflows I described, the user concept is not "intent to 
create" per se, it's "intent to edit, creating if necessary".  From a 
user point of view, I'm being asked to work on resource "foo," 
creating it if necessary.  I don't want to have to tell my client to 
do something different in the two cases.  I just want to tell it "I 
want to edit 'foo'; do the right thing."  Which, if we allow LOCK to 
create foo if necessary (as it does currently), is always done by the 
sequence LOCK / GET (but only if the GET is allowed to succeed on the 
LOCKED created resource).

I actually think (from your next message) that we agree about what 
should happen.  And I actually believe that LNRs can be changed 
fairly easily to be "empty" rather than "null" resources; all we have 
to do is remove the method response restrictions AND take away the 
"auto-delete" on UNLOCK behavior.

>  > 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.
>
>Can you elaborate on how this is a different thing?

A no-content resource is one which returns 204.  (By the way, some 
servers do this for directory resources when "default docs" and 
"directory listings" are turned off.)  The response means "there's a 
resource here but it has no body (and thus no mime type).

A 0-length resource corresponds to a 0-length file in a file system; 
it has a MIME type but no octets.

No-content resources and 0-length resources both show up in listings 
and both respond to GET.

>   It might be just as
>hard for servers to handle no-content resources (if they currently only
>handle 0-length resources) as it is to support a lock-null resource.

That's a good point.  But I'm not arguing against LNRs cause I think 
they're hard to implement :^).  I don't like their conceptual model, 
and I think we don't need to introduce them at all.

>   At any
>rate, I wouldn't support adding a completely new concept (no-content
>resources) even if we did remove the lock-null concept.

No-content resources are not new; they're in HTTP 1.0 and 1.1.

     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 14:48:56 UTC