RE: Bindings and Redirect Ref. teleconf. Mar. 1, 2000

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