Issue 101317 in chromium: Chrome incorrectly marks proxy supplied by PAC file as 'bad'

[chro...@googlecode.com]

Status: Unconfirmed
Owner: ----
Labels: OS-Mac Area-Undefined Pri-2 Type-Bug

New issue 101317 by alastair...@gmail.com: Chrome incorrectly marks proxy
supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

Chrome Version : 16.0.912.4
OS Version: OS X 10.7.2
URLs (if applicable) :

What steps will reproduce the problem?
At my university, a PAC file is used for proxy configuration (publicly
published at http://www.unimelb.edu.au/CGI-BIN/proxy.pac). In the PAC file,
only one proxy server is specified with no fallbacks.

For an unknown reason (I'm happy to publish net-internals logs if needed),
Chrome frequently flags this proxy server as 'bad' and falls back to
DIRECT. This is unfortunate, as direct internet access is not available.

What is the expected result?
Chrome either does not erroneously flag the proxy as 'bad' or realises that
DIRECT is not a valid path and continues to try the proxy.

What happens instead?
Chrome flags the proxy as 'bad' and sets a 5 minute retry. Occasionally, it
will set the retry to 1 Jan 1970. All requests thus timeout until the proxy
is cleared from the bad list.

Please provide any additional information below. Attach a screenshot if
possible.
If the bad proxy is cleared from chrome://net-internals/#proxy, Chrome
connects properly.

I realise that this is similar to issue #87336 which was closed as fixed by
r98643. Unfortunately this does not appear to have remedied the situation
described here as I am running r106469 and am still having trouble.

UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2)
AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.4 Safari/535.7

[chro...@googlecode.com]

Updates:
Labels: -Area-Undefined Area-Internals Internals-Network-Proxy

Comment #1 on issue 101317 by ahendric...@chromium.org: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #2 on issue 101317 by alastair...@gmail.com: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

URL for PAC file is incorrect - it is actually
http://www.unimelb.edu.au/cgi-bin/proxy.pac

[chro...@googlecode.com]

Updates:
Cc: bat...@chromium.org

Comment #3 on issue 101317 by mk...@chromium.org: Chrome incorrectly marks

proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

Dominic, do you know who should take a look at this?

[chro...@googlecode.com]

Updates:
Status: Assigned
Owner: asa...@chromium.org
Cc: ero...@chromium.org

Comment #4 on issue 101317 by bat...@chromium.org: Chrome incorrectly marks

proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #5 on issue 101317 by asa...@chromium.org: Chrome incorrectly marks

proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

alastair...: Thanks for reporting this. Interestingly, the PAC script you
linked to seems to just return "DIRECT" for everything. Perhaps the script
is generated?

A net-internals log would come in handy. (Instructions are found here:
http://dev.chromium.org/for-testers/providing-network-details). If
possible net-internals log capturing should be enabled at the time the
proxy is marked as bad.

If you aren't comfortable posting the log here, you can email it directly
to one of us.

[chro...@googlecode.com]

Comment #6 on issue 101317 by alastair...@gmail.com: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

I feel incredibly foolish for not realising but the PAC file is actually
specifying DIRECT as a fallback (even though it isn't a valid route).
Really sorry about this; I'll obviously have to ask my IT Department. (On
the plus side, I now know why the PAC file is kept in the cgi-bin folder).

Is it still worth keeping this open to investigate the proxy being flagged
as bad? If so, I'll collect net-internals logs on Tuesday and post them
thereafter.

Attachments:
proxy (1).pac 5.6 KB

[chro...@googlecode.com]

Comment #7 on issue 101317 by asa...@chromium.org: Chrome incorrectly marks

proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

Looks like there's one branch in the PAC script that doesn't return DIRECT
as a fallback. I'd still like to see the logs if possible.

[chro...@googlecode.com]

Comment #9 on issue 101317 by alastair...@gmail.com: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

Attached net-internals and debug logs

Attachments:
chrome_debug.log 151 KB
2ddf6d39-2e60-4281-9673-a7504e3a02c2 211 KB

[chro...@googlecode.com]

Updates:
Labels: -Action-FeedbackNeeded

Comment #10 on issue 101317 by asa...@chromium.org: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

From the log it looks like we are trying to connect to talk.google.com:5222
using SSL.

Chrome attempts to use the proxy (<proxy>:8000) to connect (Event #33 ->
#34 -> #36) and fails (TUNNEL_CONNECTION_FAILED).

Then Chrome attempts to connect directly (talk.google.com:5222) (Event #37
-> #40). A connection is successfully established.

Since the request that failed with "PROXY foo" succeeded with "DIRECT", we
mark the corresponding proxy as bad. So far so good, except DIRECT doesn't
seem to be a valid option. Subsequent connections fail.

[chro...@googlecode.com]

Comment #12 on issue 101317 by rbeck...@gmail.com: Chrome incorrectly marks

proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

I've been seeing identical/similar symptoms a lot - particularly in the
last few weeks.

Chrome marks the proxy supplied through http://wpad/wpad.dat as bad, and
will not try again.

The same proxy in another browser (Internet Explorer 9) they share proxy
settings, of course, works fine.

If I go to chrome://net-internals/#proxy, and click 'Clear Proxy'
Chrome immediately begins working again

However, it will inevitably fail within an hour. and almost certainly
fails, if I close Chrome, and re-open

I'm almost on the verge of setting chrome://net-internals/#proxy as my home
page!!!

RB

[chro...@googlecode.com]

Comment #13 on issue 101317 by ero...@chromium.org: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

Asanka made some changes to improve this. Could you send us a network log
showing how it gets marked as bad?

There are some details on how to do that here:
http://www.chromium.org/for-testers/providing-network-details

[chro...@googlecode.com]

Comment #14 on issue 101317 by samuel.d...@gmail.com: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

I'm reposting my comment made on Issue 19581 #152 as this one is more
related. After signing in sync, it shows in net-internals->proxy that the
proxy is marked as bad proxy. I also have an event PROXY_CONFIG_CHANGED
while I did not change the proxy settings.

Chrome 17.0.963.44, on WinXP, behind University proxy that have an auto
config pac.

Attached is the requested net-internals log.

Attachments:
3ab7b8f1-2e51-4066-a90c-024b59d3228f 369 KB

[chro...@googlecode.com]

Updates:
Labels: -OS-Mac OS-All

Comment #15 on issue 101317 by asa...@chromium.org: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

Thanks for the log!

As far as I can see, the bad proxy detection logic is working as expected.
The sequence of events leading up to the proxy being marked as bad are:

- Attempts to establish a connection to talk.google.com:5222 over SSL
(Event 19582: SOCKET)
1. Resolves to pac_string "PROXY proxy.server:3128;DIRECT"
2. Attempts connection via proxy.
(Event 19598: CONNECT_JOB)
- Connects to proxy and issues 'CONNECT talk.google.com:5222'
(Event 19601: SOCKET)
- Receives a 403 (Forbidden) response.
- Returns net_error = -111 (TUNNEL_CONNECTION_FAILED)
3. Attempts DIRECT connection.
(Event 19602: CONNECT_JOB)
- Succeeds
(Event 19605: SOCKET)

The proxy is marked as bad because a connection attempt that failed when
using the proxy subsequently succeeded via a direct connection.

As can be seen in event 19605, the direct connection is
talk.google.com:5222 is live and transferring data. Meanwhile, subsequent
direct connections to HTTP and HTTPS URLs fail (according to comment 152 on
issue 19581).

Since this seems to come up often, perhaps we could only consider
connections made to standard HTTP(S) ports when marking a proxy as bad.

[chro...@googlecode.com]

Comment #17 on issue 101317 by apurs...@phre.net: Chrome incorrectly marks

proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

Having same issue, I find when it "retries" it finds it fine, however I
have a "DIRECT" for failover, so it bypasses our proxy when we want it to
go through the proxy. IE doesn't do this only Chrome.

[chro...@googlecode.com]

Comment #18 on issue 101317 by ge0f...@gmail.com: Chrome incorrectly marks

proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

We've been having this issue for quite some time in our enterprise.
PACFILE works fine with IE and Firefox, but when we try Chrome it's always
labeling a 'bad proxy' and I can't browse.
I really want to use Chrome while at work, but have been unable to unless I
statically point at one of our three proxies, but this can cause slowness
issues at times due to load on that one proxy.

[chro...@googlecode.com]

Comment #19 on issue 101317 by samuel.d...@gmail.com: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

This problem still stand unresolved for me. As you suggested, did you think
about considering only connections made to standard HTTP(S) ports when
marking a proxy as bad ?

Il also want to add that I'm having this bad proxy issue with the PAC at my
universtiy when I setup the synchronisation in Chrome. If Chrome is not
connected to any Google account, everything is fine. If I want to use it
while chrome is connected, I have to clear the proxy everytime I start
Chrome which is not practical for the standard user.

[chro...@googlecode.com]

Comment #20 on issue 101317 by maar...@81square.nl: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

I'd like to add that the parsing of a PAC script for this 'test' does not
seem to take into account the fact that HTTPS connections/urls may have to
take a different route.

Our proxy script returns a DIRECT response for HTTPS urls and a PROXY
response for HTTP urls. Chrome however tries to use a CONNECT call on our
HTTP proxy during this 'test'. As our HTTP proxy will not answer CONNECT
calls, the test will fail and it will be marked as bad.

This does seem related specific to this 'test' logic, as the normal
proxy/pac operation in Chrome does seem to work just fine with HTTPS
requests (taking the DIRECT route as configured by the PAC script).

I assume this is related to this bug. If not, sorry for soiling this one. I
will open up a new one.

See attached file for example proxy.pac.

Attachments:
google-chrome-example-pac-fail.txt 1.3 KB

[chro...@googlecode.com]

Comment #22 on issue 101317 by itsk...@gmail.com: Chrome incorrectly marks

proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

Can we please have a policy option to retry after X minutes (in my case 30
seconds to 1 minute is sufficient.)

I am having a similar issue.

Running TMG 2010 authenticated proxy server - Using Chrome causes this


Technical Information (for support personnel)
Error Code: 502 Proxy Error. The number of HTTP requests per minute
exceeded the configured limit. Contact your Forefront TMG administrator.
(12219)


Basically TMG has the following the flood mitigation - Maximum HTTP
requests per minute per IP address (this is set to 600 by default)

Chrome hits this limit rather easily (I don't see this behaviour in
IE/Firefox unless I'm trying to force it to happen)

I have been seeing this behaviour since Chrome v22.

Windows 7 Enterprise x64

Chrome 23.0.1271.64 m

[chro...@googlecode.com]

Comment #23 on issue 101317 by asa...@chromium.org: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

#22: See
http://dev.chromium.org/administrators/policy-list-3#MaxConnectionsPerProxy .
Also see issue 87381.

[chro...@googlecode.com]

Comment #26 on issue 101317 by david.ka...@gmail.com: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

The line its complaining about is

iparray = ip.split(";");

Wpad file is generated by TMG

Attached - unimportant but identifying lines removed.



Attachments:
wpad.7z 1.9 KB

[chro...@googlecode.com]

Comment #27 on issue 101317 by mme...@chromium.org: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

The error from the log - "Uncaught TypeError: Cannot call method 'split' of
null".

I believe dnsResolve returns null on address failures. Null does not have
a split method. Simple modifying DnsResolve / DnsResolveEx to return an
empty list when dnsResolve returns null should fix the issue.

[chro...@googlecode.com]

Comment #28 on issue 101317 by mme...@chromium.org: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

Err...empty string, rather.

[chro...@googlecode.com]

Comment #29 on issue 101317 by david.ka...@gmail.com: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

wpad file is automatically generated, tmg does not allow me to modify to
that extent afaik.

[chro...@googlecode.com]

Comment #30 on issue 101317 by mme...@chromium.org: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

Eric: Should we be returning an empty string instead of null? I can't
find any specs, one way or another.

[chro...@googlecode.com]

Comment #32 on issue 101317 by BCDeAng...@gmail.com: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

What causes the proxy to be marked as bad? This is a growing issue in my
environment with Chrome that seems to have popped on only recently.

[chro...@googlecode.com]

Comment #33 on issue 101317 by asa...@chromium.org: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

#32: A proxy is marked as bad if a request fails via that proxy but
succeeds with another proxy or with a direct connection. The direct
connection is only tried if allowed as a fallback option.

Which version of Chrome are you running?

[chro...@googlecode.com]

Comment #34 on issue 101317 by w...@swtk.info: Chrome incorrectly marks

proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

Same problem here - Chrome 24.0.1312.57. IE and FF work fine with the proxy
PAC, Chrome marks my closest one as BAD and I am redirected to another one
(far away, topologically).
This is clearly a showstopper for enterprise deployment of Chrome.

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Comment #36 on issue 101317 by samuel.d...@gmail.com: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

This problem stands with 26.0.1410.43 m. Is there any chance to have a new
option to disable the policy defined at #33 ? Something like
--never-mark-bad-proxy ?
At my university, direct internet access is not an option on HTTP port. If
the proxy is marked as bad for whatever reasons I won't get access to the
internet until I restart the browser (or manually clear the bad proxy).
Which ports are you considering right now when marking a proxy as bad ?

[chro...@googlecode.com]

Comment #37 on issue 101317 by wyd...@gmail.com: Chrome incorrectly marks

proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

We're still seeing Chrome marking our proxies as bad when both IE and
Firefox don't suffer. It seems to be caused by our corporate web filtering
when it gets intimate with a web page and blocks certain content. Chrome
either does not understand or expect the result it gets and seems to be
treating this as a non-responsive proxy and marks it as bad. If it doesn't
mark it as bad what we may see is a web page that isn't fully rendered and
links etc don't work when clicked on.

[chro...@googlecode.com]

Updates:
Labels: Cr-Enterprise

Comment #38 on issue 101317 by mme...@chromium.org: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

wydmex: When your corporate proxy blocks content, what does it do,
exactly? A net-internals log dump of this happening would be great if your
corporate policy allows it. See
https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details
for instructions.

[chro...@googlecode.com]

Comment #40 on issue 101317 by ero...@chromium.org: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

I have split it off the request in #36 to a separate bug (issue 227288).
Certainly getting the heuristics better in Chrome is important, but having
an escape hatch for when things go wrong would help, especially in the
short term.

I understand that this causing pain for some users, and hopefully we can
come up with something that fixes that.

Taking a step back, I wonder whether the marking of "bad proxies" can be
re-designed alltogether. A few brainstorming ideas on possibilities:
- Rather than have things automatically tagged, it could be an opt-in
blacklist (i.e user needs to confirm if they want to blacklist a proxy
server)
- Be more conservative before marking a proxy as "bad" (wait for more
requests to fail, or only consider a smaller subset of requests as
problematic, etc..). For instance perhaps only low-level connection
failures to the proxy server should be considered a problem (like not being
able to open a TCP connection to it, but everything else is a "success").

[chro...@googlecode.com]

Comment #41 on issue 101317 by mme...@chromium.org: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

Or if a proxy has been used successfully, only mark it bad if we can no
longer establish a connection? Suppose that still doesn't help if you
start off vising a blocked site.

[chro...@googlecode.com]

Comment #42 on issue 101317 by mme...@chromium.org: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

wydmex:

Looking through the log you sent me, the only HTTP error I see in the log
is a request which returns "HTTP/1.1 502 Could not relay message upstream",
which takes 3 minutes for the proxy to return after we send our request. I
think this looks a lot like an issue with the proxy or the destination
website, rather than a Chrome issue. IE may deal better with a proxy
taking 3 minutes to respond to a request (Retries aggressively? Falls back
to direct connection more aggressively, if permitted?).

A bunch of the other requests are painfully slow, but they all succeed.
Since we send out the requests promptly, I can't see how those could be a
Chrome issue.

[chro...@googlecode.com]

Comment #45 on issue 101317 by wyd...@gmail.com: Chrome incorrectly marks

proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

But www.pcworld.com DOES work in Chrome, just as long as the proxy/web
filtering are not involved. Try it. ;-)

[chro...@googlecode.com]

Comment #46 on issue 101317 by mme...@chromium.org: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

Right, which is why the only thing I can think of is your proxy claiming to
be IE when it sends the request to their webserver.

[chro...@googlecode.com]

Comment #49 on issue 101317 by wyd...@gmail.com: Chrome incorrectly marks

proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

You can see the web filtering kicking in though
(http://alert.websecurity.att.com)and blocking a number of requests e.g. to
http://tags.bkrtx.com/js/bk-coretag.js?
I'm just wondering if this is unexpected and Chrome takes exception when
alert.websecurity.att.com responds and not tags.bkrtx.com which it blocked?

[chro...@googlecode.com]

Comment #51 on issue 101317 by wyd...@gmail.com: Chrome incorrectly marks

proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

Indeed, when I click on the element in the developer tools I see the
blocking page. For what it's worth I can upload a screen capture so you see
what Chrome is receiving? Is there anyway we can prove/disprove your theory?

[chro...@googlecode.com]

Comment #53 on issue 101317 by wyd...@gmail.com: Chrome incorrectly marks

proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

Hey Alistair, didn't mean to hijack your issue. I think though that
everyone that has posted here is affected by Chrome marking proxies as bad
for one reason or another.

[chro...@googlecode.com]

Comment #54 on issue 101317 by alastair...@gmail.com: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

Oh no, didn't mean it like that – it's good to see this getting some
activity!

[chro...@googlecode.com]

Comment #57 on issue 101317 by wyd...@gmail.com: Chrome incorrectly marks

proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

@mmenke, thanks will try tomorrow and report back. I don't think it is a
network issue either, I think it is probably as you stated... the
redirection to the blocking page is causing Chrome to receive a non-JS page
when it expects to receive a JS page; a scenario it's not handling all that
well.

[chro...@googlecode.com]

Comment #58 on issue 101317 by wyd...@gmail.com: Chrome incorrectly marks

proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

@mmenke

If I save the page in Chrome and open the saved page in Chrome, the links
on the page still fail.
If I open the same saved page in IE10, the links work fine.

If I save the page in IE10 and open it in IE10, it opens fine and the links
work fine
If I open the same saved page in Chrome, the links on the page still fail

In Chrome when I save the page the JavaScript is called bk-coretag.js and
in referenced inside a script tag.
bk-coretag.js however contains HTML, our blocking web page.
In IE10 when I save the page the JavaScript is called process.htm and in
referenced inside a script tag
process.htm is again our blocking web page.

If I remove bk-coretag.js or process.htm from the source files, and clear
the browser cache, and load the save page in Chrome, the links on the page
work!

[chro...@googlecode.com]

Comment #59 on issue 101317 by mme...@chromium.org: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

wydmex: Great! I'll try and reproduce. I'll also file a new bug and
inform you about it when I have a repro. May take me a while to get around
to this, unfortunately.

[chro...@googlecode.com]

Comment #60 on issue 101317 by wyd...@gmail.com: Chrome incorrectly marks

proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

@mmenke, Thanks. I'll investigate further on this side too, perhaps it will
be possible to prevent the blocked jscript being downloaded, rather than
replace it with the blocking web page. I'll ask. It's a service we buy into
though (http://scansafe.net), so not sure what our options are or if we
even have any!

So marking proxies as bad, this behaviour I assume is not a factor, it
doesn't matter how much our web filtering interferes in this manner, it's
not going to cause Chrome to start blaming our proxies and marking them as
bad?

[chro...@googlecode.com]

Comment #61 on issue 101317 by wyd...@gmail.com: Chrome incorrectly marks

proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

@mmenke Oh yes, when you repro, I suppose you'll know if it's WebKit/Blink
or V8 to blame?

[chro...@googlecode.com]

Comment #62 on issue 101317 by wyd...@gmail.com: Chrome incorrectly marks

proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

@mmenke Chrome is still behaving as per your comment (#59) Have you been
able to repro the issue and logged a new bug report?

FYI, if I install the disconnect.me extension, it intercepts/blocks
http://tags.bkrtx.com before our web filtering gets to it. This allows the
web page to work. Not a solution by any means but at least a
workaround. :-)

[chro...@googlecode.com]

Comment #64 on issue 101317 by wyd...@gmail.com: Chrome incorrectly marks

proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

Any way you can repro and get a new bug report open?

[chro...@googlecode.com]

Comment #65 on issue 101317 by pmarch...@gmail.com: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

Having the same/similar issue here & I think I have found the cause and
work-around. The proxy would get marked as 'bad' pretty regularly, between
every 2 and 20 minutes. Was able to see it being flagged as bad here:
chrome://net-internals/#proxy Reviewing the Chrome event logs
(chrome://net-internals/#events) every time this would happen, I was
noticing the following pattern, see log file attached.

Chrome was trying to connect to talk.google.com on port 5222. Apparently
this is the protocol Chrome uses to sync your personal settings. My proxy
does not allow external connections over port 5222, thus this attempt would
file, as per log, and this failure would cause Chrome to flag the proxy
as "bad" since it was not permitting this connection.

Our proxy rules have not changed so I can only assume this logic of 'mark
proxy as bad if Chrome sync failes' must be new.

Until this Chrome bug get fixed, our solution was just to allow
communication on port 5222 to *.google.com, and permit it as a SSL-tunnel
connection as well.





Attachments:
chrome-event-log-bad_proxy_list_reported.txt 2.3 KB

[chro...@googlecode.com]

Comment #66 on issue 101317 by mme...@chromium.org: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

pmarchant: Thanks for the thorough investigation! I certainly agree that
we shouldn't be marking a proxy as bad if non-port 80 request fails (Or
443, if we're supposed to be using it for SSL requests).

[chro...@googlecode.com]

Comment #67 on issue 101317 by wyd...@gmail.com: Chrome incorrectly marks

proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

Does this response mean that this issue will be looked at?

[chro...@googlecode.com]

Comment #69 on issue 101317 by samuel.d...@gmail.com: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
http://code.google.com/p/chromium/issues/detail?id=101317

Same situation as #65. See the 2 years old #15 for a trace with the
problematic CONNECT talk.google.com:5222. There is a related feature
request issue 227288 that you may want to vote for.
As for now, manually clearing the bad proxy every hours or disabling the
sync are our only options...

[chro...@googlecode.com]

Updates:
Status: Available
Owner: ---
Cc: asa...@chromium.org
Labels: -Cr-Internals

Comment #70 on issue 101317 by asa...@chromium.org: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'

https://code.google.com/p/chromium/issues/detail?id=101317

Marking as available.

[chro...@googlecode.com]

Updates:
Labels: Needs-Feedback

Comment #72 on issue 101317 by ero...@chromium.org: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
https://code.google.com/p/chromium/issues/detail?id=101317

Can people on this bug thread update with their current experience?

- Are things still broken?
- Or have you given up / worked around?

Thanks.

(I realize there are a lot of comments already over the past 4 years, but
would like to get a sense of concretely where things stand today, as some
things have changed, and then determine how to assign this)

[chro...@googlecode.com]

Comment #73 on issue 101317 by alastair...@gmail.com: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
https://code.google.com/p/chromium/issues/detail?id=101317

I'm the original reporter. Fortunately (or unfortunately) they've moved to
transparent proxying at university so I'm no longer affected by this, but
can't actually say if the underlying issue has been fixed or not. Sorry I
can't help.

[chro...@googlecode.com]

Comment #75 on issue 101317 by k...@okeefeonline.com.au: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
https://code.google.com/p/chromium/issues/detail?id=101317

Issue most certainly still exists, in fact I just had to clear the bad
proxy for this site to even load so I could write this comment...

My current work around is to have a bookmarked tab to
the "chrome://net-internals/#proxy" page and clear the bad proxy every time
it plays up (as soon as pages begin to not load again) usually at least
once an hour if not more frequently.

The other work around is to use a different browser when it sporadically
decides to occur every couple of minutes.

[chro...@googlecode.com]

Comment #77 on issue 101317 by bsnow...@coldjet.com: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
https://code.google.com/p/chromium/issues/detail?id=101317

We have been evaluating zscaler and chrome is continually marking all proxy
entries except DIRECT as bad proxies. It is usually related to traffic from
google itself. Our primary proxy does SSL mitm inspections. The backup
proxy does not do SSL inspection. The primary proxy very shortly gets
marked bad but eventually all entries do except direct. I have tried adding
exceptions to allog google traffic through unauthenticated and bypass ssl
mitm inspection but it didn't make much difference. Chrome is definitely
too aggressive marking those as bad. Has anyone simply removed DIRECT as an
option in their pac file?

[chro...@googlecode.com]

Comment #78 on issue 101317 by bsnow...@coldjet.com: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
https://code.google.com/p/chromium/issues/detail?id=101317

Here is a net internals dump. Hopefully that will help.

Attachments:
net-internals-log.json 1.9 MB

[chro...@googlecode.com]

Comment #80 on issue 101317 by bsnow...@coldjet.com: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
https://code.google.com/p/chromium/issues/detail?id=101317

I did some further testing after that. It seemed that the first proxy
timeouts happened around the time 802.1x reauth or dns changes due to the
opendns client occurred. If we delayed the startup of chrome until the
network was stable, the timeouts did not occur and no proxies were marked
bad. We haven't noticed the behavior as much recently. Don't know if a
change was made recently to clear bad proxies when a network change was
detected or chrome startup has just been delayed recently. Zscaler also had
some outages listed on their website around those times due to issues with
clients being prompted for the Google Captcha but I wouldn't have expected
that to cause timeouts or 404s from Google.

[chro...@googlecode.com]

Comment #81 on issue 101317 by rsl...@chromium.org: Chrome incorrectly

marks proxy supplied by PAC file as 'bad'
https://code.google.com/p/chromium/issues/detail?id=101317

The 404s that came back were 404s from the ZScaler itself in response to a
CONNECT message (which is not a page load). So definitely something with
the ZScaler.