On 11/29/2012 02:32 AM, Steve Hill wrote: > On 29.11.12 04:16, Eliezer Croitoru wrote: > >> I was just wondering what exactly you need to do? >> What is the goal\task of the ICAP server. > > The ICAP server does on-the-fly content filtering - it analyses the > request headers (in reqmod), the response headers and streaming content > (in respmod) to categorise the page and decide whether to block it. The > filtering criteria are done on a per-user basis, so filtering it before > it enters the cache doesn't make sense,
but categorizing a response before it enters the cache does make a lot of sense in many cases. > It would be possible to do all the possible analysis that could be > needed, insert their results as http headers and allow the object to go > into the cache, then check those headers using ACLs when it is retrieved > from the cache, but this would result in a large overhead of unnecessary > analysis since for most users those criteria are not needed. You asked for a specific example of how post-cache adaptation can be avoided. The above is such an example :-). Please note that the amount of overhead may actually _decrease_ with this solution: pre-cache + ACLs: analyze each miss + filter each access. post-cache: analyze and filter each access. Which approach results in less overheads depending on hit/miss ratios and other factors, so I do not think one can claim that only one of the two approaches make sense in general. Cheers, Alex.
