- From: Babich, Alan <ABabich@filenet.com>
- Date: Thu, 2 Jul 1998 09:04:56 -0700
- To: "'Jim Davis'" <jdavis@parc.xerox.com>, w3c-dist-auth@w3.org
Oops. I forgot about MKREF. Never mind. Yes, I agree. Sounds like we've reached closure on this. Alan Babich > -----Original Message----- > From: Jim Davis [SMTP:jdavis@parc.xerox.com] > Sent: July 01, 1998 2:22 PM > To: w3c-dist-auth@w3.org > Subject: RE: Get on a reference > > At 01:30 PM 7/1/98 PDT, Babich, Alan wrote: > >(1) GET on a reference returns 302 as per John's proposal. > >(2) PUT works on a reference, unless what is being put > >is not a reference, in which case it fails. > > Sorry, I'm confused. What do you mean? You can't PUT a reference. > You can > create one with MKREF, but not with PUT. > > In John's semantics, a client that does a PUT to a referential > resource > gets back a 302 and can then decide what to do. (Either report an > error to > the user or retry the PUT to the new URI.) If the user desires to > replace > the referential resource with one of some other type (either 'plain' > or > even a collection) the client first does a DELETE then a PUT (or > MKCOL). > > This definition allows suitable clients to make ref resources act > EXACTLY > like plain resources, as far as the user is concerned, if the user > wishes. > That's real flexibility. And it also allows clients to treat them > differently, if desired. > > Look at it this way. With most current servers you can create a > redirecting resource by writings a suitable config file somewhere. So > this > capability already exists in the Web. The only difference is that now > it > will be possible to create such redirecting resources from the client > side > alone, by invoking HTTP methods, without creating or writing any > server-side config file. > > It's a winner, I think.
Received on Thursday, 2 July 1998 12:07:37 UTC