On Tue, Mar 13, 2001 at 01:45:30PM +0100, Yves Lafon wrote:
> On Tue, 13 Mar 2001, Jean-Jacques Moreau wrote:
>
> > I think there are cases when processed blocks should not be
> > removed from messages. For example, consider a message that goes
> > through several intermediaries, and that contains some form of
> > identification (user/password, certificate, digital signature,
> > whatever), carried as a block, and used by at least two
> > intermediaries. It would be wrong for the first intermediary to
> > remove the block from the message, as it is also needed by the
> > second intermediary.
>
> In that case, targeting information should explicitely say that
> this particular block is intended for multiple processors.
I think the client should be *able* to say that it should be removed,
but won't some modules want to handle this decision internally (i.e.,
it's in the intermediary's interest to remove the module, not the
sender's)?
> If a block has been added for a specific intermediary, and if it
> doesn't impact on the main one, then it can be safely removed (note
> that auth can have an impact on cacheability)
I think that depends on the nature of the auth and caching modules
defined... while this is a behaviour of the HTTP, it doesn't have be
be for XMLP, because we have an opportunity to describe how the cache
should store the object in a much richer fashion.
--
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)