I was thinking about this for a long time. Am I right that the ISTag is not
a MUST according to the draft?
Yes, I find the ISTag idea very useful but I think there is something
missing to help a client to invalidate the data correctly.
Imagine that there are two iCAP servers running the same service in some
kind of load balancing mode. Now the configuration of the service changes in
a way that should invalidate cached data. This will not happen on both
servers at the same time. Let's assume that there is a 2 minute delay to
update the second server after the first one in this example.
During this time the client will receive two different ISTags. Which one is
the newer, the valid one? What happens if there are more than two servers,
more than one update at a time, 3 or 4 different ISTags for one service?
First I thought the answer should be a numerical order of ISTags so that the
client has a better chance but today I got a new idea when discussing this:
If the iCAP client sends the ISTag which it has stored as the current one as
a header value in its REQMOD and RESPMOD requests to the iCAP server, the
service itself has a chance to decide what to do and it knows the possible
problem better.
The service is able to understand the semantic of the ISTag while for the
client this value is opaque. The service will know from a different ISTag
than its own one that there is a sibling running with a different software
version or configuration. And so the service has a chance to react on this
if its ISTag is the older one. It could either try to get the configuration
data from its sibling automatically or it can reply with a
currently-out-of-service response and wait for the update or it can return
its normal response but add a pragma no-cache to it to indicate that its
data is not worth to cache. After the update coming soon the response will
change anyway.
I don't say that the ISTag in the requests should be forced with a MUST. But
I think it makes sense to allow and encourage them in the specs. It will
also strengthen the cookie similarity.
What are you thinking about this?
Escpecially the cache vendors. What will you do with the cached contents if
the iCAP service changes in a significant way? How will you face different
versions inside a iCAP server cluster during an update process?
Martin