Closed Bug 1514533 Opened 7 years ago Closed 7 years ago

Intermittent impossible “Unable to connect” error when Firefox is configured to use a proxy

Categories

(Core :: Networking: HTTP, defect, P3)

65 Branch
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: ambrose.li, Assigned: CuveeHsu)

Details

(Whiteboard: [necko-triaged])

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0 Steps to reproduce: Sorry, this is intermittent so there are no reliable steps to reproduce the problem. Actual results: However, when Firefox is configured to use a proxy (I’m currently using an add-on for proxy selection, but this problem happened even before I started using the add-on, and even if I hard-coded IP addresses in the configuration), sometimes Firefox will show the “Unable to connect” error (Firefox can’t establish a connection to the server at [some server name]); there are no details and the user is only offered the option to “Try again”. Expected results: 1. When Firefox is configured to use a proxy, it should never try to connect to the server. If Firefox indeed tried to “establish a connection to the server” it’s a bug in the networking code. 2. If instead, the condition is caused by the proxy misbehaving, Firefox should produce an error message that says so, and state what kind of problem it’s encountering. It is misleading to attribute connections to “the server” when said server should not be contacted in the first place. 3. If instead, the condition is caused by Firefox not being able to connect to the proxy at all, the error message is also misleading. (This is unlikely since the inability to contact the proxy does trigger a different error message—unless there’s some logic error somewhere that’s only randomly triggered.) The user also needs to be given the option to know the actual technical details. The error message, as it stands, is completely information-free and non-actionable.
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
Hello Ambrose, Although it shows Firefox/65, but I'd like to ask your Firefox version again since it could be fixed by bug 1494364. Another test is setting network.proxy.failover_timeout to 0 in about:config. Thanks!
Flags: needinfo?(ambrose.li)
Version is 65.0a1 (2018-12-09). I can try setting network.proxy.failover_timeout to 0, and/or update to the latest build, but it will take a few days to check since the problem is intermittent. FWIW, my network.proxy.failover_timeout is currently set to 18000000. I don’t know what unit that’s in, but if it’s in seconds (or even milliseconds) then Firefox doesn’t seem to be acting on this setting at all.
Flags: needinfo?(ambrose.li)
(In reply to Ambrose Li from comment #2) > Version is 65.0a1 (2018-12-09). I can try setting > network.proxy.failover_timeout to 0, and/or update to the latest build, but > it will take a few days to check since the problem is intermittent. > > FWIW, my network.proxy.failover_timeout is currently set to 18000000. I > don’t know what unit that’s in, but if it’s in seconds (or even > milliseconds) then Firefox doesn’t seem to be acting on this setting at all. It's second. If one proxy is fragile and disabled, it would be enabled again after the 500 hours in your environment.
Ok, thanks. I have set it to zero and I’ll see if that makes any difference. But FWIW, if this is what it is, my proxy is *not* disabled when this happens (i.e., opening other pages might be fine). BTW, the default value gave the same behaviour as reported; that’s why I tinkered with the default. I was assuming the setting works the same way as HTTP timeouts; I wasn’t expecting it to have the opposite effect.
assign to myself for tracking this
Assignee: nobody → juhsu
Priority: -- → P3
Whiteboard: [necko-triaged]
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Please reopen if we have more information

Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE

Well, it’s intermittent. I’ve made changes to my proxy to make it less likely to take a long time and I’ve not seen the problem since the change, so I’d say this has to do with some sort of a timeout that’s too low.

Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---

My problem with Firefox’s behaviour was not having a timeout per se, but (1) the timeout (which at the time of my report was merely hypothetical) being unreasonably low, and (2) the error message not reporting what’s actually the problem (i.e., alleging the problem to be with the target site and not mentioning the existence of a proxy at all).

(In reply to Ambrose Li from comment #8)

My problem with Firefox’s behaviour was not having a timeout per se, but (1) the timeout (which at the time of my report was merely hypothetical) being unreasonably low, and (2) the error message not reporting what’s actually the problem (i.e., alleging the problem to be with the target site and not mentioning the existence of a proxy at all).

For (1), the default value is pretty long (check network.http.response.timeout). Hence I believe there's some hints from the proxy server, based on Comment 7.

For (2), we have no way to recognize whether it's due to proxy or not. Proxy can synthesize any response/behavior, you know.

Mark WORKSFORME since comment 1 works at your side. Feel free to file another follow-up bug if there's some space to improve.

Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → WORKSFORME

If for (1) the default value is pretty long it can only mean Firefox is ignoring the default value when a proxy is involved. I also have seen my own proxy logs so I know my proxy has not responded when Firefox timed out.

For (2) because it’s my own proxy, I know that the proxy has not lied about its presence. “Proxy can synthesize any response” is irrelevant.

You need to log in before you can comment on or make changes to this bug.