On Thu, 20 Oct 2011 00:39:32 +0800, Kaiwang Chen wrote:
2011/10/19 Amos Jeffries:
On Wed, 19 Oct 2011 05:15:22 +0800, Kaiwang Chen wrote:
<snip>
To only change the HTTP headers, there are some tricks you can do
with the
"must-revalidate" and/or "proxy-revalidate" cache control. These
controls
causes the surrogate to contact the origin web server on every
request. The
origin can send back new headers on a 304 not-modified response.
Meaning the
headers get changed per-response, but the cached body gets sent only
when
actually changed. Retaining most of the bandwidth and performance
benefits
of caching.
So, the possible solution could be injecting a "Cache-Control:
must-revalidate" header by some eCap reqmod_precache service, then
Squid will revalidate the response on every request carrying new
request headers, then the origin server has its chance to set new
response headers? A little counter-intuitive workaround for class 4
adaption. Not perfect, since revalidate only occurs only when the
response is stale,
That would be 'normal' revalidation operation. Which is why the control
exists and is called must-revalidate. To override the normal operation
and force revalidation on every request.
You could set it in a filter module altering the headers. And repeat
the setup on every proxy surrogate as your expand the CDN. It is far
easier to send it from the origin which is designed to do set these
controls very efficiently and scales perfectly.
while what I am looking for is adapting every
response before it leaves Squid for the client. 'Cache-Control:
max-age=0' will force revalidation every response, though.
Otherwise known as "force reload".
Forces full erasure and new a full new fetch on every request. Not
revalidation.
I also chance read ESI which really resembles class 4 adaption with
limited capability that only modifies response body. Looks like it is
incapable of doing custom complex calculation. So Squid does not
support class 4 adaption in general? Any other alternative?
ESI, yes is good for personalization of the body. It does not exactly
do calculations. It does widget insertion in to pages for
personalization at the gateway machine. Allowing caching of the page
template and widgets separately within a CDN.
You were taking about personalizing Cookies etc, which are not part of
the body content.
NP: this trick with 304 is only possible for headers which do not
update
headers with details about the particular body object. ie you can
use it for
altering Cookie values per-request, but not for changing the
apparent
Content-Encoding from gzip to deflate. For things affecting the body
you use
the normal 200 response and send the updated body as well.
Sure.
BTW, I tried the gzip compression adapter from
http://code.google.com/p/squid-ecap-gzip/, and found that after a
request carrying "Accept-Encoding: gzip", Squid always passes back
gzip'ed response to the client, even it no longer carries that
header,
because the object is not modified. A request without gzip support
and
with 'Cache-Control: no-cache' refreshes the cache to be always
returning plain text responses. Does it imply that Squid only caches
one copy of response, rather than one per each enconding? How to make
it serve other encoding different from the cached one?
Sounds like the adapter is not working. What you describe is normal
Squid behaviour without the adapter.
IIRC the module was supposed to update the background requests to
prefer gzipped, and itself do the un-zipping when an identity encoded
response was required by the client.
Amos
