- From: Clemm, Geoff <gclemm@rational.com>
- Date: Fri, 9 Feb 2001 14:39:45 -0500
- To: ietf-dav-versioning@w3.org
I'd be happy to see this language in the FAQ (and strongly encourage Lisa to add it there), but I think it would be confusing to put something in the protocol that in effect says "for this resource, GET and PUT will continue to work as defined in HTTP", since a natural conclusion would be that we are *not* guaranteeing that they will do so in other cases. And we definitely don't want people to reach that (incorrect) conclusion. Cheers, Geoff -----Original Message----- From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com] Sent: Friday, February 09, 2001 11:47 AM To: ietf-dav-versioning@w3.org Subject: RE: Autoversion confusion Lisa wrote: > I wasn't talking only about the client that did > the put. Neither was I. In general the HTTP sever has no way of knowing which client is sending a PUT/GET request. > The DeltaV spec ought to state normatively what > OTHER clients experience. Thankfully the spec doesn't get into sessions or whatever for identifying clients. It's unnecessary. > I'll repeat from my earlier mail, my suggested language: > > "In core versioning, while a VCR is checked out it > may be the target of multiple write operations. During > this period, other clients MUST still be able to perform > read operations on the VCR's URL, and the results MUST > show the results of all the write operations that have > been performed thus far. (Note: if a scenario requires > hiding a work-in-progress from other clients, the "working > resource" option can be used.)" I'd be interested to hear if others think that we need to state this. Tim ------------------------ > > -----Original Message----- > > From: ietf-dav-versioning-request@w3.org > > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of > > Tim_Ellison@uk.ibm.com > > Sent: Friday, February 09, 2001 1:58 AM > > To: ietf-dav-versioning@w3.org > > Subject: RE: Autoversion confusion > > > > > > > > > > John wrote: > > > This shouldn't be necessary, since the HTTP spec > > > defines the behavior of GET and PUT. Specifically, > > > it says that PUT to a particular resource defines > > > the response for any following GET on that same > > > resource (I'm paraphrasing from memory). There > > > can't be any other possible interpretation (that > > > doesn't break HTTP semantics). > > > > I agree with John. > > > > At the risk of nagging<g>, a version-controlled resource is > > an honest to > > goodness WebDAV resource, with content and properties > > (version-controlled > > collections have members and properties). Intuatively, if a > > PUT to the > > resource succeeds (200 OK) then a client is entitled to > > believe they will > > GET the same entity back. > > > > p.s. > > I had a quick look through the HTTP/1.1 spec, and didn't see > > anything that > > states this categorically. In fact, Section 9.6 (PUT) states: > > "HTTP/1.1 does not define how a PUT method affects the state > > of an origin > > server." > > Now, how many clients do a GET just to check what they actually will > > retrieve after a successful PUT! > > > > Tim > >
Received on Friday, 9 February 2001 14:31:34 UTC