Re: [squid-users] How to filter response in squid-3.1.x?

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Thu, 20 Oct 2011 11:25:06 +1300

 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
Received on Wed Oct 19 2011 - 22:25:11 MDT

This archive was generated by hypermail 2.2.0 : Thu Oct 20 2011 - 12:00:03 MDT