Re: [squid-users] something better than using IP address?

Thanks Amos and Henrik, your advice means a lot to me.

I start trying the cookie + external_acl way. However...
First I don't know much about the reverse proxy. The most important
thing we care about is the interception--transparent proxy, and this
must be our bottom line. So, the question is: does reverse proxy need
user set their browser's proxy server?

As Henrik said, "If it's a reverse proxy you could use a cookie.. ".
Does that mean transparent proxy cann't use cookie? Here is what I
think. Since cookie depend on website. If my Squid server set a cookie
on the client browser, the client will only send that cookie when the
destination is ip of my Squid server. Then, in a transparent proxy
case, how can we force client browser send that cookie in every other
http request?

In addition, as both of you mentioned, the advantage of External_acl
is that every combination(e.g., ip+cookie session) is cached. In this
case, do I need to worry about the cache size(and is it configurable?)
if I have thousands of clients?

Thanks.
Jian

On Tue, Jul 15, 2008 at 12:34 PM, Henrik Nordstrom
<henrik_at_henriknordstrom.net> wrote:
> On s�n, 2008-07-13 at 01:04 -0500, Jian Wang wrote:
>> Yes, you are right. Actually, we did considered external_acl at the
>> begining. But we were worring about the performance since we were
>> aiming at a network with thousands of clients.
>
> Using an external acl performs a lot better than an url rewriter..
>
> url rewriters are called on each and every request to Squid, while
> external acl helpers is only called once for each unique combination
> seen per the external_acl_type combination.. (i.e. cookie if using
> cookies).
>
>> Actually, we are doing an Intercepting Proxy. Now I believe abandon
>> redirectors and turn to ACL is a good idea. In addition, suppose we
>> can talk to administrator of the NAT/PAT gateway, what kind of
>> information I should ask for to make my ACL work as expected?
>
> There is none to ask for. It's by design in NAT/PAT gateways..
>
> Regards
> Henrik
>
>
Received on Tue Jul 15 2008 - 18:40:07 MDT