On 25/02/2012 11:52 a.m., Guy Helmer wrote:
On Jan 29, 2012, at 5:13 PM, Amos Jeffries wrote:
On 30/01/2012 6:29 a.m., James R. Leu wrote:
Hello,
I'm in the process of implementing an ICAP server, but I'm encountering the
HostHeaderForgery issue quite often when accessing sites that I can reach
over IPv6. I've read the KB entry about this. It lists
that co-locating the NAT device and squid on the same machine,
or enabling EDNS may resolve the issue.
I'm wondering if my issue is specific to dual stack v4/v6
or to ICAP. Any suggestions for what I can try to
work around this issue? If this is specific to
dual stack v4/v6, I'm here to beat my v6 migration
drum and I'm willing to help out to resolve it.
The only relation with IP version is if you have disbaled DNS lookups of IPv4
in Squid. That could make Squid fail to identify the IPv4 destination as valid.
The latest 3.2 daily snapshot has DNS updates that work faster and obsolete
that option, so should not hit this particular aspect.
The only relation ICAP/eCAP/url-rewrite/request_header_access adaptation have
is if they alter the URL and/or Host header to something that does not sync up.
Upstream interception proxies might fail the verify and produce the conflict
error after such alterations.
The most common occurance now happening is with websites which force DNS update changes
across the Internet on very short TTL (er "load balance" via DNS results). Each
time the DNS changes IP Squid will have race between itself and client as to which picks
the change up first. DNS stability takes up to TTL duration to happen. At which point
these load balancers have de-stabilized the network again for a new IP. We have a patch
in testing now, hopefully it will be in mainstream soon.
Is there a bug # or URL from which I can obtain the patch? I am encountering
this issue with intercepting traffic to Akamai servers.
3.2.0.15 was released with the fix you need. Also for the Avira problems.
Amos
