Totally agree with you, and at the same time - do not agree. But, consider the following situation. There is https://site.net/ where there is 1.jpg and 2.jpg. If I download from this site 1.jpg from the address 1.1.1.1 and 2.jpg from the address 2.2.2.2. Even more. There are situations when you need to release a certain connection to the Internet through a single provider (for example, mobile), but you need to download the largest file that is never physically downloaded by this connection. On another no way. Squid theoretically these are several computers (by the number of incoming connections) and, what prevents us as different computers from using different outgoing interfaces even for the same origin address? I'm not saying that you need to push the unbroken. Look at the problem from the other side. For example, in Chrome, I set up a proxy 1.1.1.1 and download https://site.net/1.jpg. At the same time in Mozilla I set up a proxy 2.2.2.2 and download https://site.net/2.jpg. What's the difference if you set up the same one squid? acl 1s-jpg url_regex ...1.jpg acl 2s-jpg url_regex ... 2.jpg tcp_outgoing_address 1.1.1.1 1s-jpg tcp_outgoing_address 2.2.2.2 2s-jpg Where is the entrance here? Why do we try to shove it into one hole, if we can divide it into separate processes. It may even need some new key or ACL to determine that for these connections to create always new tunnels (TLS, ssl, certs, ...) acl separate_this CreateNewTunnelForNewLink >> Question: how can we break the established channel (unpinn it) along >> the old route and establish a new channel along the new route, when we >> already know how. > Squid supports using multiple sequential connections for the same > from-client request, but not under the conditions you describe. > Moreover, the already supported cases are limited to simpler HTTP/TCP > failures. Complex code modifications would be required to support what > you want for HTTPS, but it is doable, and others have wanted a similar > "peek and then start from scratch" feature. >> I'm willing to pay a large price for traffic congestion in this case, >> since the goal justifies it. > Please note that some origin servers may have a different opinion about > this trade off: Some might view (repeatedly) terminated innocent > sessions as an attack and block all your traffic. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
