Re: POST vs. separate methods

Note: I recognize that cache consistency could be considered outside the
purview of the distributed authoring group, so I can certainly understand
if others think this discussion should be moved. On the other hand, it
seems to me that resolution of this issue is essential to the proper
functioning of distributed authoring systems.

On Tue, 29 Oct 1996, Larry Masinter wrote:

> 
> There's both a previous GET and a subsequent one:
> 
>     GET a / modify b / GET a
> 
> where the first & second GET use the same cache but the Modify uses a
> different cache. In such a situation, the cache used by GET has to
> know to revalidate for the second one: it either has to revalidate
> every time or else somehow be notified. I can't think of any way
> around this situation.
> 
> I think this could be handled by adding a requirement on HTTP clients
> (or intermediate proxies in a chain) that switch between proxies:
> 
> If the client(proxy) has performed an UPDATE on a given URL, and then
> switches to a different (subsequent) proxy, the client should include
> in each request to any potentially affected URLs a 'max-age' which is
> less than the time since the last UPDATE.
>

The difficulty here is tha the processes involved my be unrelated, even
unaware of eachothers' existence. If they reside on separate hosts they may
follow different proxy chains simply because of network topology and no
switching of proxies involved.
 
> The simplest way to implement this is just use 'time the proxy server
> changed', and the next simpler is just to remember, for each host, the
> time since the last update method to that host. Of course,
> finer-grained information can be kept.
> 
> This still puts the implementation burden on 'caches that can switch
> proxy servers', which is probably where it belongs.
> 
> Larry
> 

One possibility that presents itself is to use the Via: header. Since the
resource itself resides on only one host, there is absolute time. In
particular, from the origin server's point of view, the requests affecting
a given resource cqan be totally ordered. Now, if the origin server always
returns a resource with an entity tage containing the Via: header from its
most recent update, then a client doing a subsequent GET will be able to
determine that an update followed a different proxy chain and therefore
know that it must revalidate the resource.

---
Gregory Woodhouse     gjw@wnetc.com
home page:            http://www.wnetc.com/
resource page:        http://www.wnetc.com/resource/

Received on Tuesday, 29 October 1996 16:08:44 UTC