mnot’s blog

Design depends largely on constraints.” — Charles Eames

Thursday, 6 May 2010

RFC5861: HTTP Stale Controls

On a bit of a roll, RFC5861: HTTP Stale Controls has (finally) been published as an Informational RFC.

As discussed before in “Two HTTP Caching Extensions,” these are very useful ways to hide latency and errors from your end users. While they’re most useful in HTTP gateway caches (a.k.a. reverse proxy caches / accelerators), very latency-sensitive sites might find them useful as well when working with “normal” proxy caches.

Both are implemented in Squid 2.7. Not only does Squid respect both response Cache-Control directives, but it also allows you to tweak its behaviour using the stale-while-revalidate and max-stale refresh_pattern options. Squid 3.2 should have them when it’s released, and I understand that Apache Traffic Server will have stale-while-revalidate available soon as well.


Filed under: HTTP Standards Web

5 Comments

Guilherme Silveira said:

Great news, because its already supported in Squid, updating our current reverse proxies shall take a couple minutes.

From the first post, are there other similar situations where Yahoo found that similar extensions would leverage the caches role, but were left out?

Regards

Tuesday, May 11 2010 at 3:05 AM +10:00

Guilherme Silveira said:

Btw, the cache channel draft expired a while ago, and is so easy to implement on servers, besides it seems to add value for websites with hundreds of resources that change not so often. Any plans on its future?

Tuesday, May 11 2010 at 3:10 AM +10:00

Randy Hudson said:

There is no need for a stale-while-revalidate directive. Instead, they gray region in your diagram could just represent the last XX% of the resource's freshness window. If an incoming request is received during that tail part of the window, the cached response is returned (and is still fresh), with an asynchronous request still being used to expand the freshness window for future requests.

All you really need to know is when you asynchronously re-fetch the resource, its freshness will be a function of when you fetched it. Using the delta "max-age" directive (instead of "Expires") would seem to suggest this today.

Either way, if requests 2 and 3 are never received, 4 ends up blocking while the cache is refreshed.

Wednesday, May 12 2010 at 10:51 AM +10:00

Jon Moore said:

Hi Mark, thanks for shepherding this through. Do you happen to have any notion of whether there is any interest and/or activity in adding support for these directives to modern browsers' caches? i.e. do you know of submitted feature requests open on Firefox, Opera, Chrome, Safari, IE, etc.

Friday, May 14 2010 at 10:09 PM +10:00

Mark Nottingham said:

Randy -

That wouldn't work for cache hierarchies; when the child cache(s) pre-emptively request to refresh their cache, they'll get something with a very small freshness window, and they'll be forced to revalidate (and block the client).

Jon -

Not to my knowledge, although the pre- and post-check features in IE are functionally similar (but IMHO more confusing to use).

Cheers,

Monday, May 17 2010 at 1:11 PM +10:00

Creative Commons