Re: More content negotiation

[I've limited the Cc: on my response to the http-caching list.]

Daniel writes:
    I'm not a big fan of any scheme that purposely defeats the ability
    of a proxy to serve cached objects because of user-agent rendering
    differences.  However, some people seem intent on doing this, so it
    has to be addressed.

This gets to the "Correctness is more important than performance"
goal.  In particular, I would guess that it's probably more important
for a cache to return the same variant that the origin-server
would return, than for the cache to avoid contacting the server
at all.  It's not necessarily a question of "defeating the ability
of a proxy to serve cached objects", but rather of "requiring
the proxy to check that it is not serving the wrong cached object."

I understand that "wrong" here may be relative.  For example,
if the user has a slight preference for JPEG files over GIF files,
and the server has both JPEG and GIF versions of an image
but the proxy has only the GIF version cached, is it OK for the
proxy to return the GIF file?

Perhaps yes, if the user's preference is based on retrieval time.
Perhaps no, if the preference is based on some other metric (storage
space?).  I wonder if the content-negotiation mechanism can really
express the full nuances here.  It may be that the cache needs should
have the option of using a slightly less-preferred variant instead
of contacting the server, but I would hope that this could be
expressed explicitly in the content-negotiation headers.

    But, I'm not convinced any HTTP headers or protocol changes can
    overcome or signifigantly reduce the performance hit of the
    existance of opaque variant-picking schemes.

We may find it impossible to allow the proxy to pick the right
variant from its cache in every case, and unacceptable to require
it to contact the server in every case.  But this may simply mean
that we need to split the problem into "easy" cases and "hard" cases
(or perhaps "easy", "hard", and "impossible" cases) and define
somewhat different proxy algorithms for each class of cases.

For example, an easy case might be "the server says there is exactly
one variant, so the proxy always returns it".  A hard case might
be "the server provides enough information to choose between
variants, and so the proxy makes the choice."  An impossible case
might be "the proxy is unable to make the choice, and so must
present the request to the server, perhaps along with some
indication of what possible responses it already has in its cache."

-Jeff

Received on Thursday, 28 December 1995 22:27:23 UTC