ERR_NO_SUPPORTED_PROXIES error on dev and canary versions of Chrome

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use a dev/canary version of Chrome
2. Go to any HTTP website such as http://www.cnn.com

What is the expected output?
The proxy should work.

What do you see instead?
Seems that Google did yet another code change that breaks the extension. The 
initial HTML source code seems to load properly, but the stylesheets and 
Javascripts don't load, and when you reload the page, you'll get the error code 
ERR_NO_SUPPORTED_PROXIES.

What version of the product are you using? On what operating system?
Reproducible browsers on my side:
- Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) 
Chrome/40.0.2176.0 Safari/537.36
- Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like 
Gecko) Chrome/39.0.2171.2 Safari/537.36
- Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, 
like Gecko) Chrome/39.0.2171.7 Safari/537.36

Original issue reported on code.google.com by ngyikp on 3 Oct 2014 at 12:13

Attachments:

• datacompressionproxy.png

[GoogleCodeExporter]

It works fine in my Chrome Dev 39.0.2171.13. What do you see on 
chrome://net-internals#proxy?

Original comment by jerzyglowacki on 10 Oct 2014 at 11:09

• Changed state: NeedInfo

[GoogleCodeExporter]

Using 40.0.2183.0 canary:

Effective proxy settings

Proxy server for HTTP: https://proxy.googlezip.net:443
Bypass list: 
  <local>
  10.0.0.0/8
  172.16.0.0/12
  192.168.0.0/16
  fc00::/7
  *-ds.metric.gstatic.com
  *-v4.metric.gstatic.com
Recently failed proxies, marked as bad  

Bad proxy server    Time for next retry
compress.googlezip.net:80   2014-10-10 19:18:33.428
https://proxy.googlezip.net:443 2014-10-10 19:18:33.428

Original comment by ngyikp on 10 Oct 2014 at 11:17

[GoogleCodeExporter]

Goglezip proxies should not be bad, what happens when you click "Clear bad 
proxies" and reinstall the extension?

Original comment by jerzyglowacki on 10 Oct 2014 at 11:29

[GoogleCodeExporter]

Trying on a clean user profile, with all extensions disabled, still having 
issues :(
Video demo so you can see what's going on: 
https://dl.dropboxusercontent.com/u/1286251/images/datacompressionproxy-weirdnes
s.mp4

I'm tempted to write this off as dev/canary bugginess, but this has been 
present for about 2 weeks and seems highly unusual.

It seems to work fine on 37.0.2062.103 stable, I'll try to get installs of 
Chrome 38 stable and Chrome 39 beta.

Original comment by ngyikp on 10 Oct 2014 at 11:46

[GoogleCodeExporter]

Actually, I just inspected the network and found this error. Duplicate values 
in the chrome-proxy header?

Original comment by ngyikp on 10 Oct 2014 at 11:56

Attachments:

• ScreenClip.png

[GoogleCodeExporter]

we have the same problem after ubdating chrom to 40.0.2183.0

Original comment by khalid00...@gmail.com on 10 Oct 2014 at 1:58

[GoogleCodeExporter]

I can reproduce it in Chrome Dev 40.0.2182.3. Google have messed up their 
algorithm again. Now they always add the following request header when using 
the proxy, regardless if it is already set by the DCP:

chrome-proxy: ps=1234567890-1234567890-1234567890-1234567890, 
sid=1234567890abcdef, b=2182, p=3, c=win

where:
b - the build number
p - the patch number
c - the client type

These requests get back from Google servers with the failing response:

status: 502
chrome-proxy: block=0
connection: Proxy-Bypass

However, even chrome.declarativeWebRequest.RemoveRequestHeader({name: 
'Chrome-Proxy'}) doesn't remove those headers.

I will have to investigate it further.

Original comment by jerzyglowacki on 13 Oct 2014 at 10:39

• Changed state: Accepted
• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Does the DCP work fine for you in the Incognito mode (you have to allow the 
extension to run in incognito mode first)?

Original comment by jerzyglowacki on 14 Oct 2014 at 9:47

[GoogleCodeExporter]

Sorry for the late reply, yes, it does work fine in incognito (40.0.2189.0 
canary)

And the extension also works fine on stable and beta

Original comment by ngyikp on 15 Oct 2014 at 10:19

[GoogleCodeExporter]

Same as here. This is weird, seems like Chrome is automatically adding the 
Chrome-Proxy header in normal mode. I have filed a Chromium issue about it.

Original comment by jerzyglowacki on 16 Oct 2014 at 7:20

[GoogleCodeExporter]

Issue 28 has been merged into this issue.

Original comment by jerzyglowacki on 16 Oct 2014 at 9:30

[GoogleCodeExporter]

I have hopefully fixed this issue in version 1.5 by setting a fallback proxy 
using the PAC script.

Original comment by jerzyglowacki on 20 Oct 2014 at 12:57

• Changed state: Fixed