Re: HTTP Caching Model?

Dan pointed out a general problem with the current content-negotiation
scheme within the presence of a caching proxy.  Paraphrasing, the problem
is that a proxy cannot mirror the behavior of the origin server without
knowing the same content availability information as the origin server. 
In other words, the caching proxy needs to know what variants are available
in order to determine what the origin server's response would be, and thus
whether that response has already been cached.

Although it is possible to track cached responses via accept headers and
user-agents (as Dan and Jeff mentioned), that solution will not scale
because there is a much higher variability in Accept* and User-Agent
request headers than there is in URIs with negotiable content.

Since, in reality, only a small portion of URI space is capable of
generating variants, I think a more general solution would be to have
the server explicitly declare what variants are available (if any)
as part of the response metainformation.  The proxy could then use
that information as the guide for determining the correct response.
In fact, separating the metainformation from the message entity will
be necessary in any case in order to cache multiple entities per URI.

People who follow the URC discussions will probably notice that, in
sending the information on variants, the server is essentially saying
what subset of the URC for that resource is available from that server.
In fact, I am sure that some would argue that, when variants are present
for a specific URI, the server should just respond with a URC and allow
client redirection to find the specific non-variant URL desired.

So, the way I see it, we have several choices:

  1) Keep the current model and just say it doesn't work with proxies

  2) Patch the current model by adding a "Variants:" header like

        Variants: text/html;qs=1;bs=9653;ua="Mozzilla",

     which would ONLY be sent when the given URI allows variants;

  3) Implement a standard scheme for client-based redirection upon receipt
     of variant metainformation (i.e. a URC).

If the answer is (1), then I think all mention of content-negotiation
and the Accept* headers should be removed from HTTP/1.0.

(2) is easy to implement (because only proxies and servers sending variants
would need to change), but it does not seem to be a good long-term solution.

(3) is, surprisingly enough, relatively easy to implement -- all that would
be needed is a new 3xx response code and at least one format for enclosing
URCs in the message body.  There are two that I can think of:

      Content-type: text/iafa-template
      Content-type: text/prdm

The latter is for the Partial Redundant Distributed Metalanguage
described at <>,
though it is used in their implementation for a different purpose.
This is a much better long-term solution (because it also enables
URNs), but I think I'd have a hard time calling it HTTP/1.0.

What do you think?

......Roy Fielding   ICS Grad Student, University of California, Irvine  USA

Received on Tuesday, 13 December 1994 21:31:31 UTC