W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2001

FW: RE: Issue: NEED_FOR_PUTL

From: Jim Whitehead <ejw@cse.ucsc.edu>
Date: Mon, 23 Apr 2001 12:44:28 -0700
To: "WebDAV WG" <w3c-dist-auth@w3.org>
Message-ID: <AMEPKEBLDJJCCDEJHAMIEEDNCNAA.ejw@cse.ucsc.edu>
Accidentally caught by the spam filter. I've added Ron Jacob's email address
to the accept2 list.

- Jim

-----Original Message-----
From: Ron Jacobs [mailto:rjacobs@gforce.com]
Sent: Monday, April 23, 2001 11:18 AM
To: WebDAV WG
Subject: [Moderator Action] RE: Issue: NEED_FOR_PUTL


Is there, or should there be, anything in WebDAV that prevents a server
from refusing to process any PUT requests for an unlocked resource?

Seems to me that this issue fits cleanly into the set of decisions that
are left to the server implementer and that can be decided without impacting
WebDAV compliance.

Thanks, Ron

-----Original Message-----
From: Clemm, Geoff [mailto:gclemm@rational.com]
Sent: Saturday, April 21, 2001 6:32 AM
To: WebDAV WG
Subject: RE: Issue: NEED_FOR_PUTL


We certainly should not restrict the behavior of PUT to only accept
writes if the resource is locked (for the reason given in 2518,
namely interoperability with non-locking clients).  The If header
allows you to specify that a PUT should only succeed if the resource
is locked, so I see no reason to add a PUTL method.

So I agree with Jason's conclusions (i.e. reject this proposal).

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:ccjason@us.ibm.com]

<<
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JanMar/0186.html

The description of the issue is:

Is there a need for a PUTL (put which succeeds only if the resource is
locked) method to avoid certain classes of overwrite conflicts, or a need
to
restrict the behavior of PUT on WebDAV servers to only accept writes if the
resource is locked?
>>
Once again, just to get discussion going... I'll note that there hasn't
seemed to be a lot of people asking for this so I'd suggest in the interest
of keeping the spec simple that we defer this proposal until there appears
to be more demand.   The proposal actually provided for an option that
didn't require a change to the functional spec so that remains an option
for those that might later discover that this is important.

I guess I'd consider a proposal to recomend that people lock resources
before they do PUT on them.  I'd actually prefer to not even do that
though. I think we've made the issues clear enough in the spec.  People can
chose to put a lock on the resource if they want.

Other opinions?

J.
Received on Monday, 23 April 2001 15:46:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:56 GMT