On the connection between content negotiation and caching

[This was originally an exchange between a small number of people,
and in particular, a response to Larry Masinter.  I realized after
I sent it that it could be of interest to the HTTP caching subgroup.
I hope Larry doesn't mind that I'm quoting from a message of his.
-Jeff]

Larry writes:
    The 'cache' issues for content-negotiation
    are the same as thhe cache issues for authentication.

That might be true, but I don't think it's obviously true.

    That is, once you've authenticated to a site, you supply
    credentials with every request.  However, some requests (e.g.,
    embedded GIF images) don't require credentials. So the server needs
    to say whether the results 'vary' (e.g., succeed or don't) based on
    credentials. And you don't want the cache to decide whether
    credentials are valid.

This is sufficient if the goal is simply correct caching.  That
is, if you are only concerned with ensuring that the cache ultimately
returns the right response, whether it comes from the origin
server or the cache.

But I perceive a general desire to further optimize performance;
that is, if two requests with slightly different preferences would
result in the origin server returning the same response, then if
the cache already holds that response, it would be nice if the
cache could return it (subject to validation constraints), rather
than re-fetching it from the origin server.

I don't think the proponents of this position have fully articulated
how it could or should be accomplished, but I think they have made
a case for at least trying to accomplish it.

I can think of at least one important case where a simple optimization
might work nicely: when the server *knows* that there is exactly
one response no matter what preferences are expressed (i.e., there
are no other variants besides the current response), then it could
mark the response as "non-varying".  This would allow the cache
to match the response URL against the URL of subsequent requests,
and to ignore the Accept headers in those cases.

Maybe I'm being naive, but I would imagine that this is the common
case (especially for intra-organizational web servers) and could
be implemented without much pain.  But to me it seems different from
the authentication case, since it requires that the server return
what amounts to a prospective "don't care" indication about parts
of the request headers.

 -Jeff

Received on Thursday, 28 December 1995 01:37:19 UTC