Re: I-D Action: draft-nottingham-linked-cache-inv-00.txt

What do you think about allowing the origin server (or an intermediate
proxy, for that matter) to indicate a new Last-Modified timestamp for
a related resource, rather than just indicating that any cached copy
of the related resource should be considered invalid?

Here's the use case where I think a Last-Modified update would be useful:

Consider a website on which most HTML pages reference a stylesheet,
    <link rel="stylesheet" href="/common.css">
In common practice, common.css is with a large max-age value to
encourage downstream caching.  Eventually a web developer will modify
the document at the origin server, and it will become important that
any client that subsequently requests any HTML resource from the site
must also fetch the new version of the stylesheet.  A common solution
for this is to add versioning information to the URI -- e.g.,
/common.css?v=2 -- but that's a cumbersome technique for many reasons.

The linked cache invalidation isn't quite a match for this scenario.
The server could send an inv-by the next time each client requests any
HTML page,
    Link: </common.css>; rel="inv-by"
but that should only be sent once per client, so as to avoid
invalidating the cache on every subsequent HTML resource request.  And
in the general case it's impossible to keep track of what clients have
already received the inv-by.

But what about the following variant?
    Link: </common.css>; rel="last-mod"; value="[some valid HTTP-date]"
Upon seeing that header in the response, the recipient (whether the
origin client or an intermediate cache) could decide whether to
invalidate its cached copy of /common.css based on the supplied
last-mod timestamp.  It would be safe for the server to send that
header to the same client (or intermediate cache) arbitrarily many
times.

-Brian

Received on Saturday, 28 May 2011 10:40:58 UTC