Issue metadata
Sign in to add a comment
|
chromium swaps proxies on mtalk.google.com:5228
Reported by
geert.n...@gmail.com,
Nov 3 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.78 Safari/537.36 Steps to reproduce the problem: 1. Create a proxy.pac with fallback proxy, for example: return PROXY proxy1.domain.com; PROXY proxy2.domain.com 2. Surf around on the web. Take a website that connects to mtalk.google.com:5228 I though it was related to SYNC, so i logged myself out, but that didn't change anything. 3. I am behind a corporate firewall and this one blocks requests to :5228. Chromium interprets this as "an invalid proxy" and switches to the second proxy. So this behaviour leads to frequent proxy switching and if the backup proxy is across a WAN, to increased WAN traffic What is the expected behavior? don't switch proxies on a non-standard port or timeout. The proxy is clearly alive. (switching to the backup won't help as this one will also block that request) What went wrong? no crash. Did this work before? N/A Chrome version: 60.0.3112.78 Channel: n/a OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version:
,
Nov 3 2017
,
Nov 3 2017
Most firewalls block :5228 port. However, when Chrome connects to this via proxies, it leads to Chrome incorrectly "invalidating" the proxy server (while nothing is wrong with the proxy). I have confirmed that adding the following line to the top of your proxy.pac file removes the issue: if ( shExpMatch(lhost,"mtalk.google.com") ) return 'DIRECT'; For this specific domain return direct. Even if this "direct" request will fail, at least it will prevent Chrome from invalidating the other proxies.
,
Nov 7 2017
,
Nov 7 2017
Thanks for the report! I agree with your assessment of the problem and workaround with the PAC. We have seen this failure cause in other environments too. This falls under Issue 680837 . A heuristic that considers proxy failures only on non-standard ports would certainly be reasonable for your use-case. But given the diversity of failure reasons, we should have a more general solution that encompasses this. One possibility would be to require N failures before de-prioritizing the proxy, rather than just 1. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by geert.n...@gmail.com
, Nov 3 2017178 KB
178 KB View Download