- From: Clemm, Geoff <gclemm@rational.com>
- Date: Fri, 11 May 2001 23:12:54 -0400
- To: ietf-dav-versioning@w3.org
I agree with Tim's point that Cache-Control: no-cache is not needed for the VERSION-CONTROL response. Does anyone object if we remove this requirement during the IESG last call period? (Note: I also agree with all the other points Tim has made in this thread). Cheers, Geoff -----Original Message----- From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com] Sent: Friday, May 11, 2001 6:25 PM To: ietf-dav-versioning@w3.org Subject: AW: VERSION-CONTROL with Location header? > From: "Stefan Eissing" <stefan.eissing@greenbytes.de> > Date: Fri, 11 May 2001 13:20:55 +0200 > > Tim, > > thanks for taking the time for this informative answer. > I did not consider the example with the working resource > being deleted on a checkin, which makes the Location > header a necessity. This is indeed not the case with > VERSION-CONTROL. > > However, in Section 3.5 it says: > "If the request-URL identifies a version-controlled resource, > the resource just remains under version-control. > This allows a client to be unaware of whether or not a server > automatically puts a resource under version control when it > is created." > > Which I read more like "...keeps the client from knowing > whether there was anything done to the resource or not." There is no intent here to deceive the client. Since servers are free to put resources under version control as they are created this is merely a convenience (someone requested) for clients. The convenience saves clients having to query the resource to see if it is already under version control, or dealing with benign 'errors' from the server. Clients can always create a resource (say, PUT) then send VERSION-CONTROL to ensure it is under version control, and the server is required to make VERSION-CONTROL a no-op on version-controlled resources. > See, I'm implementing WebDAV client/gateway code which works > against a remote WebDAV server. Due to performance reasons > I have to cache resource state (at least for a short time). > So, it would be nice to know if VERSION-CONTROL changed the > resource or not (keeping my cache valid). This could be done > with a Location header or via the response code, whatever. As a caching proxy you would also have no way to know if the resource was changed by VERSION-CONTROL. (Interestingly, the spec calls for the response of VERSION-CONTROL to set the "Cache-Control: no-cache" response header, which, in the circumstances, seems unnecessary. > An optional Location header would have the advantage, that > client can be unaware, if they wish, while clients which like > to know can look for the header. For a while we had responses of 201 Created if the resource was put under version control, and 200 OK if it was a no-op. The problem would only arise if you are caching live properties aswell as content and dead properties since VERSION-CONTROL does not change the content or dead properties of the resource at the request-URI. If you are caching live properties it is likely that you will have other cache consistency problems too. Tim
Received on Friday, 11 May 2001 23:13:32 UTC