[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] [I#97] Caching Mechanism
I think use of the caching mechanisms is always optional, but there
definitely need to be a well defined set of rules for when the mechanisms
are used. I would suggest that the cache keys are always scoped by the
Producer and that the ability of one entity to invalidate the markup of
another entity is a desirable use case. The worst case is just a reduction
in the cache hit rate, not a security issue.
Another (and likely larger) issue raised in the last discussion on this
issue is whether we would define a validation cache scheme or an
invalidation cache scheme. Has anyone worked through those issues since
that discussion?
Andre Kramer
<andre.kramer@eu. To: wsrp-wsia@lists.oasis-open.org
citrix.com> cc:
Subject: RE: [wsrp-wsia] [I#97] Caching Mechanism
10/24/2002 06:38
AM
One possible security issue I see is that the consumer may end up trusting
the producer or the entities in a producer as there are no proposed
security controls on what content can be invalidated (Only from same
producer? Or same application groupID from that producer?) or on two
entities specifying the same validation key (should keys be unguessable
unique identifiers?). We do not want a hostile entity deleting or spoofing
another's content because of a trusting/open and shared consumer-side
cache. I'm sure sensible rules are possible but we should make the
validation caching mechanisms optional if trust is an issue.
regards,
Andre
-----Original Message-----
From: Gil Tayar [mailto:Gil.Tayar@webcollage.com]
Sent: 23 October 2002 07:46
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#97] Caching Mechanism
Caching has long been forgotten in these days of heated discussions
on initEnvironment and groupId :-). I would like to return and
discuss it.
There are two proposals on the table. One of them is defined in the
v0.8 spec, and the other is a mechanism proposed by myself and
extended by Yossi and Mike. Is anybody interested in pursuing this
mechanism, or should we just leave the current one (defined in the
spec)as it is? The main difference between the two is that the
mechanism in the draft only includes expiration semantics, but does
not include validation/invalidation semantics. Since most Web apps
use validation/invalidation and not expiration semantics (because
usually expiration time is never well defined for most apps), I
believe the validation/invalidation to be important. The proposal
(copied below), attempts to address this.
Gil
P.S. For reference, here is the proposal (without Mike's extensions,
but with Yossi's)
6.1 Operations [getMarkup]
[instead of expires in markupResponse, add the following]
cacheControl: A data structure, defined in Section 11, which includes
information which CAN be used by the Consumer to cache the markup.
This structure includes:
validityPeriod: The number of seconds during which the markup is
valid. During that time the Consumer CAN use its cache entry instead
of calling getMarkup.
validationTag: The Consumer SHOULD store this tag along with the
markup while the markup is cached. This enables the Producer to use
this tag to invalidate the cache entry by sending an
invalidationTagPrefix in the performInteraction operation. After the
markup expires, the Consumer CAN send the validationTag in the
markupResponse to indicate that it still has the markup but would
like to validate it. The Producer returns a fault response [TBD] to
indicate that the markup is still valid, otherwise if it returns
markup , the Consumer MUST invalidate the old markup.
cachingScope: This is an enumeration field used by the producer
to tell the consumer what is the caching scope of the markup.
Possible values for this field are:
1 - session. The markup is invalid outside the scope of the current
client session.
2 - user. The markup is only valid for this user, regardless of his
session.
3 - producer. All requests for this resource can be served by one
valid cached markup.
While this is not an explicit part of the protocol, The consumer
SHOULD also not use a cached markup in any scope that was generated
for a different locale/markupType/mode.
[add to markupContext the following field]
validationTag: This field CAN be sent to indicate that the
Consumer has cached markup (which was tagged by the Producer with
this value) and wishes to check whether it is still valid. See
validationTag in markupResponse for more information.
6.1 Operations [performInteraction]
[add the following field to interactionResponse]
invalidationTagPrefix: If the Producer returned this value, the
Consumer MUST expire all markup-s who's validationTag begins with
this value. The Consumer MUST not call getMarkup with these
invalidationTag-s to validate these expired markup-s.
Hopefully this proposal gives good coverage of different caching
scenarios for consumers/producers that make full use of it, while
degrading gracefully for those that make use of only some of the
elements. For example, many producers will probably not use the
validation tag, and some consumers will probably only do per-user,
per-URL caching, but they can still make use of the more basic
parameters (like validity period). It may be a good idea to also add
some metadata describing these capabilities in the producer and
consumer metadata.
-----Original Message-----
From: Gil Tayar [mailto:Gil.Tayar@webcollage.com]
Sent: Wed, October 09, 2002 06:56
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#97] Caching Mechanism
I totally agree with Rich's comments on Mike's email. The first
proposal
(array of invalidationTagPrefixes) is just a simple extension. No
questions.
The others raise some questions, and invalidate the concept of a
"simple"
caching mechanism.
Proposal: incorporate Yossi's extension, albeit using strings and not
numbers, add an extension mechanism as per Mike's proposal, and
change the
returned invalidationPrefix to be an array of such, as per Mike's
proposal.
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Mon, October 07, 2002 21:08
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#97] Caching Mechanism
I would note that as Carsten's proposal was incorporated in v0.7 that
the
standard extensibility was added to CacheControl.
I would agree that we are using string arrays (maximizes
interoperability)
rather than enums throughout the protocol.
On the first (b) comment, are you proposing there be a structure for
the
invalidationTagPrefix or could this just use the fact the
InteractionResponse structure is already extensible?
From Yossi's original proposal, I would agree that the invalidation
information in InteractionResponse would be better as an array. While
it
often would often be used with a size of one, this gives significant
power
to the entity at minimal cost to the Consumer.
The later three proposed extensions are quite specific to how a cache
might
be implemented. The extensibility of the data objects certainly would
allow
this information to be carried between end-points that
understand/support/exploit it.
More fundamentally, are we interested in getting the validationTag
concept
and its related semantic implications on the various operations into
v1?
"Tamari, Yossi"
<yossi.tamari@sap To:
wsrp-wsia@lists.oasis-open.org
.com> cc:
Subject: RE:
[wsrp-wsia]
[I#97] Caching Mechanism
10/07/2002 02:37
PM
Hi Mike,
I agree that my proposal missed the necessary extensibility
properties.
They should be added to all relevant objects.
I do not see a difference between enumeration and string in your
first c.
Both can be extended. We seem to be using strings with predefined
constants
elsewhere in the spec, so I agree with this remark as well.
I don't think we should add the 4 extensions that you offered
(especially
the later two), because they seem to cross the line between
simple-in-a-complex-way to complex-squared, and between generic to
vendor-specific.
Yossi.
-----Original Message-----
From: MICHAEL.FREEDMAN [mailto:MICHAEL.FREEDMAN@oracle.com]
Sent: Monday, October 07, 2002 6:04 PM
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#97] Caching Mechanism
Yossi, your proposal is the best so far. It provides a good
semantical framework for the type of caching we have found
useful in
our Portal. It also seems to draw a reasonable line of being
"enough" function without getting overly expressive and
complex.
However, there are needs (by ourselves and I suspect others) to
at
times be overly expressive and complex. Hence we would like to
see
[more] extensibility built into the mechanism. I.e. view the
semantics you have defined as "base" semantics but allow for
extended
support/semantics where applicable.
For extensibility, we need the proposal to:
a) Add an extension field in the cacheControl structure
to
carry additional information
b) Allow extended information to be returned with the
invalidationTagPrefix from a processAction
c) define cachingScope in the getMarkup's cacheControl
return
structure in an extensible manner. A suggestion is to
define
cachingScope as a String. "session", "user", and
"producer"
would be predefined, well understood scopes. However,
cooperating consumers and producers could additionally
use
vendor specific scopes.
By adding these to the proposal we would have both a good
basic
level/semantic of caching and allow vendors like us to
support/express a greater level. A few specific "extensions"
that we
think it would be better if the base proposal incorporated
directly
would be:
a) you can return multiple [invalidation] tags from a
processAction. Tags are still "prefixes", however there
is
value in returning multiple prefixes to accurately prune
a tree
whether at a leaf or higher up.
b) you can return multiple tags in a cacheControl
structure
from getMarkup. I.e. the validationTag field is a list.
The
semantic of this is each tag is a discrete invalidation
key for
the content returned from this getMarkup. Supporting
this give
a producer the flexibility to categorize cache content
along
different dimensions and invalidate accordingly along a
dimension.
c) you can return an urgencyToExpire value along with the
invalidation tags from processAction. This field would
express
how quickly the cache must attempt the invalidation.
I.e.
invalidate these keys but its okay if you are busy to
continue
serving "stale" data for a given duration. There is one
field/value for the entire list of tags returned.
d) you can return an urgencyToExpire value in the
cacheControl
structure from the getMarkup. Similar to the function in
(c),
this directs the cache as to the urgency of invalidating
the
cache if/when one goes "out of scope" where scope is the
cache
scope defined by cachingScope.
We strongly urge these "extensions" be considered and added
into the
proposal as they have good value and would be somewhat clumsy
to
express in the extension mechanism. However, if that is not the
consensus of the group, as long as your proposal carries at
least the
minimal extensibility defined at the top we would have enough
mechanism to express the above function.
-Mike-
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC