not a security bug, so tagging for network>proxy team.

The PAC file attached contains a script error:

	if (isInNet(resolved_ip, "10.0.x.x", "255.0.0.0") ||
		isInNet(resolved_ip, "172.16.x.x,  "255.240.0.0") ||
		
		return "DIRECT";

no there is not an issues i took out the missing line.n  sorry did not realize it.  here is the correct statement.


The PAC file attached contains a script error:

	if (isInNet(resolved_ip, "10.0.x.x", "255.0.0.0") ||
		isInNet(resolved_ip, "172.16.x.x,  "255.240.0.0") ||
		isInNet(resolved_ip, "216.189.xx.xx", "255.255.255.0"))
		return "DIRECT";s not an issues 

An export of the Network Log (https://dev.chromium.org/for-testers/providing-network-details) would probably be the fastest way to see what specifically is going on here.

Without that, I'm not sure what you mean when you say "proxy blocking page". If a proxy fails to return a proper response for a given resource (see  Issue 680837 ), it can be marked "Bad" and Chrome is designed to fail over to the next proxy in the list. The line:

	return "PROXY 10.190.x.x.:8080; DIRECT";

(which I assume has a valid IP address instead of "10.190.x.x.") means "First use the proxy, and if the proxy fails, go DIRECT." So failing over to DIRECT in the event that the proxy fails is expected behavior.

Agreed with comment #4.

Almost surely a dupe of  Issue 680837 . I can't understand your description, but I expect the situation is that your proxy is failing the request, so Chrome sends the request directly per the PAC script.

Subsequent requests will also go straight to DIRECT for the caching period of "bad proxy" (5 minutes).

Can you confirm in what manner the proxy fails? (Is it during the CONNECT?)

So I see the block happening on my proxy as expected.  But on the local machine the page loads.  

IF your proxy attempts to block a response, but you allow fallback to DIRECT, we'll fall back to using DIRECT connections, depending on how your proxy blocks requests.  You should remove the DIRECTs if that's not the behavior you want.

This was never an problem till last week.

I think we're going to need the log requested in #4, gathered using a command line flag, as we can see what's going on (--log-net-log=C:\some_path\some_file_name.json)

Unfortunately, to get startup events before you open net internals, we'll need a log collected using a command line flag.  Please launch Chrome with "--log-net-log=C:\some_path\some_file_name.json" and upload the log at the path you give on the command line.

The log in #13 doesn't contain any network requests. Did you perform your repro scenario (attempting to load the page that should be blocked) after starting chrome with the flag?

Since that log was generated by --log-net-log, it should have events in it (You can tell it was generated correctly because it's missing the other tab).  It should, at a minimum, have loading the NTP and background requests we make on startup.

[eroman]:  I don't suppose you know of anything that may have broken that recently?

Not sure why the log didn't contain many events.

For capturing the log, I would suggest just using chrome://net-export/.

Once you start logging, click the button to clear bad proxies on chrome://net-internals/#proxy, then reproduce the problem.

From the description though, it sounds like you are expecting the request to FAIL however it succeeds?

Per comment #7, since your PAC list includes DIRECT any failure exclusive to the proxy wouldn't matter, since it would still try direct.

If that is not what you want, why include the fallback to DIRECT?

IN the past the it has always block.  NO matter what.  

IT should only go direct if the proxy cant be reached.  IF the page gives you a deny then it page should not try a second request. 

I agree that a 403 error should generally be a target failure and not considered a proxy failure. However maybe something else is going on -- like for instance the proxy is returning a 403 during tunnel establishment rather than a 407.

See comment #18 on getting a NetLog which shows *why* the proxy got marked as bad.

If this only started failing for you recently, could be a change in your proxy settings or proxy server behavior, or something that changed in Chrome. There shouldn't have been any changes to the fallback logic, but we can send you instructions on running a bisection if the log doesn't give the answer.

the proxy never got marked as bad.  T Hat is the problem  The proxy gave a DENY or block page  403 error.  WHy should chrome see a 403 DNEy as a bad request

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

it working in IE and firefox with no issies

Per comment #21 we can't make progress without seeing a log.

And for the record, returning 403 from a proxy sounds like a broken proxy. If the proxy itself is mandating auth it should be returning a 407 not a 403. We can only speculate without a log.

I believe the point here is that the proxy is attempting to censor the content available to the user, by failing connections to unwanted domains (e.g. the gambling domain in #16). 

If Chrome considers a proxy's 403 response to a CONNECT to mean that the proxy has failed, the presence of DIRECT as a fallback proxy in the FindProxyForUrl result circumvents the administrator's intent to use the proxy as a censor.

FWIW, handling of proxies that return a 403 in response to CONNECTs *seems* to have changed between Chrome 63 and Chrome 65 at least, as seen in the attached screenshot.

Deleted: FallbackProxyChange.png 40.4 KB

	FallbackProxyChange.png 40.4 KB View Download

(Removing myself from CC list since I don't actually know anything about proxies.)

Hrm. Attempting to bisect the difference observed in #27, I find that Chrome falls back to DIRECT in Chrome 61-66, and I see the same thing in Chrome 39. So I cannot explain why I got the behavior in that Chrome 63 screenshot, and sadly my machine updated and I cannot retry in that install. 

Can you please escalate. 

Thanks everyone for the data and experiments.

tl;dr: This is a duplicate of  issue 680837 . I will follow-up on that thread. I expect we will resolve this by changing Chrome's long-standing policy around CONNECTs, such that it no longer attempts fallback (which better aligns with other browsers).

RE comment #27: I tested against 63.0.3239.132 and couldn't reproduce any difference in policy. Are you sure your test setup was correct? Chrome's policy around CONNECT has been unchanged for a long time, so I do not believe there was any recent regression.

I am still very skeptical about the "PROXY 10.190.x.x.:8080; DIRECT" use case as a means of blocking content. While I am willing to make a concession in how Chrome handles this to satisfy compatibility, it isn't right to try and use this for any sort of privacy or security mechanism around filtering.

Note that during the course of my testing with Edge (which doesn't mark proxies that fail during CONNECT as bad), I got into a situation where my test proxy got blacklisted and the requests started flowing to DIRECT. I don't know why Edge considered it bad -- perhaps it experienced some spurious connection level error? At any rate, the consequence was that all that traffic simply went DIRECT as in Chrome, which does underline the robustness and predictability issues around making assumptions that proxy fallback cannot happen.

In edge i do get blocked apond further investigation we are only seeing this issue happen with ssl sites.