Re: cache-busting document

Andrew Daviel:

>Martin Hamilton wrote:
>> >Don't use redirects, since their results are uncacheable.
>> 301 is cacheable, 302 is not. Use what you need.

Even 302 is cachable under 1.1, if you send along the right
Cache-Control directives.  And the response to the GET request which
resolves the redirection is always cachable (unless marked as
uncachable).

>When I wrote this, no-one used 301. A redirect isn't a big hit, anyway,
>but if the net's truly bad it might make a difference where a 
>hierarchy cache might otherwise serve a cached page without checking it.

I think that dynamic redirects to cachable documents are a very much
under-used tool for increasing web cache efficiency: use of such
redirection should be encouraged, not discouraged.

If you have the time to dig them up from the cookie threads, see my
comments about how advertising sites could use redirects to increase
ad image caching efficiency without loosing user counting.

>>>   Don't use content-negotiation until HTTP 1.1 is more widely
>>>     deployed, since in HTTP/1.0 it interacts badly with proxy caches.
>>What am I supposed to use until then?
>
>Not many people do, anyway. Doing it via a redirect is a compromise;
>it works, the pages themselves are cacheable, but it requires two
>requests not one.

Yes, redirects are a often a good compromise.

Some notes here: HTTP/1.0 interacts badly with proxy caches for
negotiated material, but HTTP/1.1 interacts only slighty better.  If
you really want to deploy negotiation with a clear conscience as far as
caching is concerned, you have to wait for the deployment of
transparent content negotiation.

Even so, early adopters of transparent content negotiation may want to
use redirection responses a lot, especially when returning content to
1.0 systems not capable of transparent content negotiation.
Transparent content negotiation allows a variant resource to be a
resource which returns a redirection response to the real data, and I
would recommend that early adopters use such variant resources if the
real data is very large.

Authors of negotiation modules in servers could do a lot to make use
of redirection hacks in negotiation as easy as possible for content
authors.

I don't think that the advise `don't use content negotiation until X'
will do any good.  Many authors have very legitimate needs for
negotiation, and they would be better served by a document telling
them how to use redirection to negotiate in a cache-friendly way.

Of, course, there is always a tension between offering more
representations and getting a higher cache hit rate on your
representations.  The latest TCN draft has some language on this
issue; feel free to cut-and-paste.

In one way, the brokenness of HTTP/1.x negotiation is a good thing:
the inability of the server to know the screen size of the browser has
saved us from sites which use server-side .gif scalers to customise
the returned content up to the last pixel.

And note that TCN (at least the initial version under consideration
now) won't be an enabling technology for server-side .gif scalers
either.  This limitation is very deliberate, even though it also rules
out the legitimate use of server-side rendering engines to
custom-tailor content for very buggy browsers.

>Andrew Daviel

Koen.

Received on Wednesday, 11 June 1997 13:26:55 UTC