Re: [squid-users] Dynamic Client Bypass

Joe Cooper wrote:

> 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.
>>
>>
>>
>>
>>
>>
>
>
>
Well... as soon as I knew about this solution I coded a small perl
daemon to do this.... the only thing that I noticed was the RETRY
header, which could not be sent by my daemon, but it could be done in
squid..

I might try to code de squid part, although I don't have much time, I'll
see what I can do.. I might share this perl code to squid-users so that
anybody can use it... but I'll run some tests tomorrow with telcom first..

Thanks

-francisco
Received on Wed Jul 17 2002 - 15:06:22 MDT