W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

AW: VERSION-CONTROL with Location header?

From: <Tim_Ellison@uk.ibm.com>
Date: Fri, 11 May 2001 23:25:13 +0100
To: ietf-dav-versioning@w3.org
Message-ID: <80256A49.007B3931.00@d06mta07.portsmouth.uk.ibm.com>


> 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 18:26:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:41 GMT