W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1998

RE: MKREF on existing resource

From: Slein, Judith A <JSlein@crt.xerox.com>
Date: Fri, 4 Dec 1998 10:18:04 -0500
Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76D26@x-wb-0128-nt8.wrc.xerox.com>
To: "'Jim Davis'" <jdavis@parc.xerox.com>, w3c-dist-auth@w3.org
The reason for 3.3.1 was strictly to keep MKREF analogous with PUT, but I
agree that this is not satisfactory if the resource that's being replaced is
a collection.  It also raises a sticky issue about whether MKREF on a direct
references gets passed through.  I like your suggestion that we just forbid
MKREF on an existing resource.  So that's what I'll do unless anyone

As I was looking through the spec for problems this change might cause, I
noticed another change that probably should be made.  In the section on
dangling direct references, I said that PUT, MKCOL, and MKREF should
succeed, but that really doesn't make sense.  PUT should succeed.  But MKCOL
and MKREF should fail, I think.  MKCOL would fail for a healthy direct
reference, and it would be odd if the fact that a reference was broken could
make it succeed.  The same holds for MKREF if it gets passed through; if it
doesn't get passed through, it should fail because it's being applied to an
existing resource. 


Judith A. Slein

> -----Original Message-----
> From: Jim Davis [mailto:jdavis@parc.xerox.com]
> Sent: Thursday, December 03, 1998 10:05 PM
> To: w3c-dist-auth@w3.org
> Subject: ACR: MKREF on existing resource
> 3.3.1 says "If a MKREF request is submitted for an existing 
> resource, the
> existing resource's content and headers will be overwritten.  
> This behavior
> is analogous to the behavior of the HTTP PUT method. "
> I would prefer to forbid MKREF on an non-null resource.
> My objections to the specified behavior are:
> 1. It is problematic if the resource is a collection.  It 
> gives MKREF some
> of the semantics of DELETE.  Near as I can tell, WebDAV does 
> not allow PUT
> to a collection, or at least leaves it undefined.  Why allow MKREF?
> 2. We don't allow MKCOL on an existing resource, why allow MKREF?
> I don't see any real advantage to it, either.  The only 
> advantage I can see
> is that if there are existing dead properties they will be left
> undisturbed.  If we decided instead that one must DELETE, 
> then the client
> would have to PROPFIND (to get copies of the properties), 
> then PROPPATCH (to replace the properties).  This does not seem
> unreasonably burdensome to me, and it simplifies  things.
> Finally, strictly editorially, I don't know what it means to 
> 'overwrite
> headers'.
> best wishes
> Jim
Received on Friday, 4 December 1998 10:13:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:15 UTC