Re: [squid-users] Dynamic Client Bypass

That part of the equation is non-existent. You'll have to code it into
Squid, pay someone to code it, or get by with "next time you try it, it
will work" and use a script to watch the access.log for relevant errors,
as Henrik suggested (which also does not currently exist, but I'll be
happy to give advice and some code snippets that I've written for
tailing the store.log and acting on the information that goes by--it
certainly isn't a complete solution, but will get you started if you are
familiar with Perl).

I've been meaning to write something like this for some time, but just
haven't gotten the spare time to do it. I'm swamped these days, and
have too many bills to pay to take time off from paid work.... I have
the basic components (a log tailing daemon script, and an iptables rule
program that can add bypass rules) but no time to integrate them, and
work out just what errors to watch for and how best to reply to them.

Francisco Obispo wrote:
> Ok... we'll run some test with telcom department to see how it does
> tomorrow..
>
> but what about the HTTP retry message?
>
> -francisco
>
>
> Joe Cooper wrote:
>
>> Francisco Obispo wrote:
>>
>>> Joe Cooper wrote:
>>
>>
>>
>>>> Worth noting: Francisco is using WCCP. This presents the additional
>>>> problem of how to get past the router without the packet being
>>>> redirected back to the cache in a theoretical infinite loop, because
>>>> the IP when routing through the cache machine will remain the client
>>>> IP. The only way around this I know of is to use policy routing on
>>>> the router, wherein the last-hop is checked and WCCP is bypassed if
>>>> the cache is the last hop. As I understand it, the ability to route
>>>> based on last-hop is not a common feature on most Ciscos and
>>>> requires an upgrade to an advanced policy routing module (I don't
>>>> know enough about Cisco routers or the various IOS branches to know
>>>> the specifics of this).
>>>
>>>
>>>
>>>
>>> Well... I wonder how Cisco Cache Engine Deals with this... because
>>> according to
>>> http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/net_cach.htm#xtocid13
>>>
>>>
>>> <CiscoSite>
>>> if the server responds to the cache engine with certain HTTP error
>>> return codes (such as 401-Unauthorized request, 403-Forbidden, or
>>> 503-Service Unavailable), the cache engine will invoke the dynamic
>>> client bypass feature. The cache engine will dynamically store a
>>> client IP-destination IP address bypass pair, so that future packets
>>> with this IP address pair will bypass the cache engine. The cache
>>> engine sends an automatic HTTP retry message to the client's browser.
>>>
>>> </CiscoSite>
>>>
>>>
>>> it doesn't say anything about the router being involved in the
>>> process... also, the Cisco Cache Engine will send and automatic HTTP
>>> retry message, which has to be sent in this case by squid which has
>>> the active conection with the client.
>>>
>>> I don't see an easy solution to this... except acls in the router,
>>> which will lead to mantain a very very large list of sites with
>>> ip-based authentication. :^/
>>
>>
>>
>> Actually, there is one easy solution (which Henrik pointed out in a
>> private email) which is to put the cache on another network interface
>> which is not redirected via WCCP. This has its own potential pitfalls
>> (minor and easily worked around, assuming you have a spare interface
>> you can put your Squid machine on), but makes bypassing in the cache
>> very easy. Using last-hop policy routing also works around it and
>> prevents you from needing the access list to be maintained on the
>> router. In these two cases (which are reasonable in many
>> environments, but not all) all decisions for bypassing can be handled
>> in the cache itself. Otherwise it gets complicated...and the
>> situations where it gets complicated are the most common, in my
>> experience.
>
>
>
>
>

-- 
Joe Cooper <joe@swelltech.com>
Web caching appliances and support.
http://www.swelltech.com