- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Mon, 6 Mar 2000 12:18:50 -0800
- To: WebDAV WG <w3c-dist-auth@w3.org>
I agree with Geoff -- the Overwrite header isn't ideal for this case, since it has "delete first" semantics, and is always associated with the Destination of a COPY/MOVE, not the Request-URI. - Jim > For both current uses of the Overwrite header (COPY and MOVE), the use > of Overwrite means to first delete the resource (if any) that exists at > that location. I.e.: > > 8.9.3 MOVE and the Overwrite Header > > If a resource exists at the destination and the Overwrite header is > "T" then prior to performing the move the server MUST perform a > DELETE with "Depth: infinity" on the destination resource. > > 8.8.4 COPY and the Overwrite Header > > If a resource exists at the destination and the Overwrite header is > "T" then prior to performing the copy the server MUST perform a > DELETE with "Depth: infinity" on the destination resource. > > To define its semantics for MKREF to differ in this regard > seems likely to result in confusion and errors on the part of > implementors. > > In the past, I've proposed that we extend the Overwrite header to allow > a "Merge" value (i.e. Overwrite:Merge). If we did so, then the use of > of "Overwrite:Merge" would allow us to consistently use MKREF and an > Overwrite header to update the value of the redirect reference. > > Cheers, > Geoff > > > -----Original Message----- > From: Greg Stein [mailto:gstein@lyra.org] > Sent: Friday, March 03, 2000 5:30 PM > To: Slein, Judith A > Cc: 'Joe Orton'; WebDAV WG > Subject: RE: Bindings and Redirect Ref. teleconf. Mar. 1, 2000 > > > Why would it have to delete the properties? > > Overwrite is defined to "... overwrite the state of a non-null destination > resource ...". It is specified in terms of a COPY/MOVE, and we can state > that for a MKREF, it *only* overwrites the target. > > There is no other language that forces us to interpret Overwrite as > "DELETE the resource first [implying the props are deleted]". > > I really like Joe's idea. > > Cheers, > -g > > On Fri, 3 Mar 2000, Slein, Judith A wrote: > > It's certainly a possibility. > > > > The only problem I can see with relying on MKREF is that it > would not just > > update the target, but would replace the resource with a new resource. > > That's probably harmless if it's an HTTP resource with no > properties, but > if > > it is a WebDAV resource it might have properties that you would like to > > preserve while updating its target. > > > > --Judy > > > > -----Original Message----- > > From: Joe Orton [mailto:joe@orton.demon.co.uk] > > Sent: Wednesday, March 01, 2000 7:05 PM > > To: WebDAV WG > > Subject: Re: Bindings and Redirect Ref. teleconf. Mar. 1, 2000 > > > > > > > Issue #6: Need to add rationale for why we use relative URLs. > Server is > > > required to store it as a relative URL. Server MUST NOT change the > > relative > > > URL during a MOVE. > > > > > > Raises the issue of needing separate methods for getting the > value of a > > > reference, and modifying the value of a reference. Tentatively agreed > on > > > REFGET, REFSET (but noone likes these too much). > > > > The original -00 spec allowed MKREF with Overwrite, could this be used > > instead of REFSET? > > > > joe > > > > -- > Greg Stein, http://www.lyra.org/ >
Received on Monday, 6 March 2000 15:18:48 UTC