On 11/28/2012 11:26 AM, Steve Hill wrote: > On 28.11.12 16:19, Alex Rousskov wrote: > >> Yes, it is both very far from trivial and, in most cases, avoidable >> by redesigning the adaptation approach itself. I have seen many use >> cases that started with a post-cache requirement, but were successfully >> massaged into avoiding one. > > Can you explain this in a little more detail? The results of my ICAP > server are dependent on the user that is requesting the object, so doing > the work in respmod_precache would result in the modified object going > into the cache and then being retrieved by other users who would need > different modifications. I can't really see a way around this other > than making the objects all uncachable, which rather defeats the purpose > of having a cache. :)
There is no one-size-fits-all adaptation approach, of course. Sometimes it is possible to reshape adaptation so that post-cache adjustments become unnecessary, sometimes it is OK to make just the pre-cache adapted responses uncachable or cachable with Vary, sometimes it is OK to cache nothing, and sometimes one ends up running two proxies like you have described. The latter is why I think post-cache adaptation is worth supporting in Squid. Cheers, Alex.
