- From: Dan Brotsky <dbrotsky@Adobe.COM>
- Date: Thu, 28 Jun 2001 11:36:07 -0700
- To: "Lisa Dusseault" <lisa@xythos.com>
- Cc: <w3c-dist-auth@w3.org>
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