"semantically transparent" (was Re: More small edits to draft 04a)

    >     semantically transparent cache
    >       A cache that does not affect the semantics of a request and the
    >       resulting response.  A response is considered to be unaffected by
    >       the cache when the client receives a response equivalent to what
    >       it would have received if it had made the request directly to the
    >       origin server.

    Is it necessary to bind "equivalent"?  I was thinking in terms of
    entity comparison, wherein the origin server sometimes doesn't
    require exact equality.

I think it's best to think of the weak-validator cases as approximations
to semantic transparency (in exchange for improved performance).  Since
this is an aspect of the cache's behavior with respect to a particular
request, not an aspect of the cache per se, that's one reason for
my suggested retitling of the definition:

    >    semantically transparent
    >       A cache behaves in a "semantically transparent" manner, with
    >       respect to a particular response, when its use affects neither
    >       the requesting client nor the origin server, except to improve
    >       performance.  When a cache is semantically transparent,
    >       the client receives exactly the same response (except for
    >       hop-by-hop headers) that it would have received had its request
    >       been handled directly by the origin server.
    
    Do you really want it defined as no affect on the origin server?

That's not quite what I meant.  Not "no effect on the origin server"
but "no effect different from what would happen if the cache wasn't
involved".  So, for example, the omission of any side-effects on the
origin server would be considered a failure of transparency.

    That would make it impossible for any cache to be semantically
    transparent because they interfere with demographic collection
    (even log forwarding is not enough to avoid that affect).
    I think that would make the definition less than useful.
    
The definition is useful because the rest of the spec discusses
(in many cases) how we try to *approximate* semantic transparency.
If an origin server really does care about demographic data, then
it needs true semantic transparency from caches (i.e., same
side-effects as if the cache were a tunnel).  The current HTTP/1.1
spec provides the must-revalidate directive as a crude way of
doing this; my (failed) proposal for max-uses/use-count would have
been somewhat more efficient for this.

Generally, every time a cache revalidates with the origin server, and
doesn't use a weak validator to do that, it preserves semantic
transparency for the interaction.  The client sees what it would have
seen had it made the request directly to the origin server, and so does
the origin server.

-Jeff

Received on Thursday, 6 June 1996 17:17:06 UTC