]> git.ipfire.org Git - thirdparty/squid.git/commit - src/http.cc
Author: Mark Nottingham <mnot@pobox.com>
authorAmos Jeffries <squid3@treenet.co.nz>
Tue, 25 May 2010 10:30:55 +0000 (22:30 +1200)
committerAmos Jeffries <squid3@treenet.co.nz>
Tue, 25 May 2010 10:30:55 +0000 (22:30 +1200)
commit3d8b6ba4c6e56fa095348ff59329b858d2eae5a7
treec35284c8c5ee60de4ea3d695081c8aa82fc8b832
parent0e1d762939f6c520ba41c222dcc7d51610b4916c
Author: Mark Nottingham <mnot@pobox.com>
Bug 2631: store-stale refresh_pattern option

RFC2616 allows almost anything to be cached*; most of the constraints are on
what can be used out of cache.

For example, this response:

HTTP/1.1 200 OK
Content-Type: text/html
Date: [date]

[ content ]

is cacheable as per HTTP; it just is considered stale as soon as it is cached.

However, Squid (and many others) don't cache all of these responses, at least
in part because doing so would decrease cache efficiency, and introduce more
load (e.g., on disk subsystems, etc.).

In particular, Squid won't cache a response unless it has either explicit
freshness (e.g., Expires, CC: max-age) or a validator (Last-Modified or ETag).

Nevertheless, doing so is desirable in some circumstances, because in some
deployments the client wants to be able to ask for a stale response. For
example;

GET /foo HTTP/1.1
Host: example.com
Cache-Control: max-age=3600, max-stale

Should retrieve the above response from cache, as long as it is less than an
hour old.

This patch adds a 'store-stale' refresh_pattern option that allows this.
src/cache_cf.cc
src/cf.data.pre
src/http.cc
src/structs.h