Re: Explicit revocation

On Thu, 28 Dec 1995, Ari Luotonen wrote:

> So the conclusion is, it would make a lot of sense to at least provide
> a possibility for the origin server to take the responsibility of
> contacting the proxy back to let it know if something has suddenly
> changed before its given expiration date.
> 
> This has at least a couple of things to worry about, though:
> 
> 1. the origin server has to maintain a list (for every document) of
>    proxy servers that contacted to it during the last X period of
>    time; alternatively, it could be a single list of proxy sites, and
>    once things change (there may be a batch process run once an hour),
>    the changes would be reported in batches to the proxy sites
> 
> 2. the proxy may be unreachable from the server (firewall letting only
>    outbound connections from the proxy)
> 
> Opinions?

This is an approach I've been advocating for some time. Burried in a recent
post from me was a similar suggestion.

1. HTTP servers need to be more distributed data base like and in doing
   so reasonable data structures would exist for tracking which proxies
   requested notification of status change.

   My earlier comments suggested that the proxy would notify the owner
   (or down stream proxy) how long it might cache the document. Never
   longer than the current expires in any case.  During the might be
   cached interval, the owner would notify the proxy of changes.

2. Many firewall proxies would still be reachable but if they choose to
   not be reachable, they wouldn't add the might cache for header and
   hence wouldn't be notified.

The W3C WEB Collaboration work ship/ notification working group has 
discussed cache management as one example of notification usage. So
I would address the issue of how to notify client proxies of change by
having the server proxy 'send a notification'. Delivery of notifications 
would be a reliable process. I think multiple alternatives are needed.
For closely cooperating proxy/server combinations, a notification might
be kept open and the notifications would be delivered in real time.
An HTTP server to proxy method could be defined for sending batches of
one or more notifications. Or it might be a different port, etc. to
handle the security fire wall issues.

This is a bit high level and there is a lot more to consider for a 
general notification mechanism but cache purging is a good candidate.

And, a proxy could decide to refresh immediately w/o a specfic client
request if the changed page was used frequently, or it could queue
a request for idle time, or it could purge the cache. The notification
could, with appropriate human author input, be such that it tells
a cache that a new version is available but the old version is OK to
serve until the updated version is available (in which case the notification
could also be batched/delayed etc.) or the change notification could
require immediate purge because a new corporate policy has been announced.

Dave Morris

Received on Friday, 29 December 1995 03:23:16 UTC