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@xxxxxxxxxxxxxxxxxxx> 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 > >
