Closed Bug 790321 Opened 7 years ago Closed 7 years ago

Firefox fails to recover after temporary proxy disconnect (SOCKS)

Categories

(Core :: Networking, defect)

15 Branch
x86
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla19

People

(Reporter: tomiii, Assigned: mcmanus)

References

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20100101 Firefox/15.0.1
Build ID: 20120905151427

Steps to reproduce:

Configure firefox 15 for manual proxy: SOCKS v5 localhost:1080
Start SSH proxy tunnel (e.g. "ssh -D 1080 remotehost")
Load pages in tabs (e.g. gmail)


Actual results:

If the SSH proxy is temporarily terminated and then firefox attempts to load a page, this fails as expected. However, restarting the SSH proxy is not sufficient to make firefox start working again. Firefox fails to reconnect to the newly restarted SOCKS proxy.

Workarounds: Restart firefox, or toggle the "Work Offline" checkbox on and then off again.


Expected results:

Firefox should should automatically reconnect to the SOCKS proxy when it becomes available.
Component: Untriaged → Networking
Product: Firefox → Core
Summary: Firefox fails to recover after temporary proxy disconnect → Firefox fails to recover after temporary proxy disconnect (SOCKS)
I think this is a regression of bug 641937.
Blocks: 641937
Keywords: regression
Reporter, could you reproduce it when you are configuring the proxy address using IP address (127.0.0.1:1080 for IPv4 or [::1]:1080 for IPv6)?
New information: The problem appears to be specific to gmail. I didn't realize this when I submitted the original bug. When the SOCKS proxy is restarted, gmail fails to resume functioning. I see this message at the top of the gmail screen:

  "Oops… the system encountered a problem (#000) - Retrying in 2:02…"

Opening URLs to other non-gmail sites appears to work correctly after a SOCKS proxy restart. Now I'm not sure if this is a firefox problem or a gmail problem. I cannot reproduce this with Google Chrome. It only happens with firefox.

Confirmed that problem still exists when configuring the proxy as follows:

Manual proxy configuration
SOCKS Host: 127.0.0.1  Port: 1080
SOCKS v5
No proxy for: localhost, 127.0.0.1

I have to toggle "Work Offline" on/off to make gmail work in firefox 15.0.1 whenever my SOCKS proxy is restarted (wish there was a keyboard shortcut for this...)
Reporter:
Please open about:config, confirm the warning, enter "spdy" in the top filter bar without the quotes and change "network.http.spdy.enabled" from "true" to "false"
Now test again after a Firefox restart and don't forget to switch the option back to true after you are done.
I saw three different "enable" settings for spdy in about:config

network.http.spdy.enabled
network.http.spdy.enabled.v2
network.http.spdy.enabled.v3

I tried all 8 combinations of true/false values for these (restarting firefox each time) but no combination allowed gmail to keep working after a SOCKS proxy restart.
regression keyword from comment 1 ruled out by comment 3
Keywords: regression
Thomas - this is works for me using linux and a ssh based socks proxy on localhost in both ff15 and the nightly ff18 which closely matches your report. I connect to gmail, kill the ssh, get the complaints in gmail, start ssh again, and gmail automatically starts working again.

I guess we need an http log of you demonstrating the failure and we'll see if we learn anything from that

https://developer.mozilla.org/en/HTTP_Logging
I see the same issue with socks proxy after we enabled spdy on samba.org servers. Try opening www.samba.org, then wiki.samba.org via socks proxy is giving really strange results with firefox and spdy enabled. Setting network.http.spdy.coalesce-hostnames to false makes things work even with spdy enabled, maybe that is the buggy part.
I disabled spdy again on the wiki as this socks SPDY bug is actually a blocker for an enrollment. Sorry that you cannot use that for reproducing the Firefox bug any more now.
What I could see is that requests to are being sent to the wrong host. That means calling https://wiki.samba.org and https://www.samba.org alternately via a socks proxy that had a disconnection resulted in requests to wiki being sent to www or vice versa. I could also see the effect that Firebug actually showed that when the wiki site is opended all the content of the wiki site was being loaded but Firefox did actually still display the www site.
With a bug like this you really should not have SPDY support enabled by default becuase it actually prevents sites from turning on SPDY, this is a disservice to the SPDY development.
bjoern did you only see this when using a proxy? I think I can see why that might have been a problem
yes, this is only happening with socks proxy only. You can still see the effect actually. set up a socks proxy via "ssh -D 127.0.0.1:1080 127.0.0.1" and set 127.0.0.1:1080 as socks proxy in firefox. Then visit https://www.samba.org https://wiki.samba.org https://bugzilla.samba.org in some random order. Then you will probably see that after you opened https://www.samba.org (the only spdy enabled host currently) and then open https://wiki.samba.org that the wiki site is not being displayed but the www site is displayed instead.
Attached patch patch 0Splinter Review
HTTP proxies were excluded from coalescing logic, but SOCKS proxy were not.
Assignee: nobody → mcmanus
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #674216 - Flags: review?(honzab.moz)
Comment on attachment 674216 [details] [diff] [review]
patch 0

Review of attachment 674216 [details] [diff] [review]:
-----------------------------------------------------------------

r+ with just a minor design detail.

::: netwerk/protocol/http/nsHttpConnectionInfo.cpp
@@ +84,5 @@
> +        return false;
> +    const char *proxyType = mProxyInfo->Type();
> +    if (!proxyType)
> +        return false;
> +    if (!strcmp(proxyType, "direct"))

Since there is a private kProxyType_DIRECT for this literal, I'd rather add a new method to nsProxyInfo like bool IsDirect() or so.
Attachment #674216 - Flags: review?(honzab.moz) → review+
(In reply to Honza Bambas (:mayhemer) from comment #13)
> Comment on attachment 674216 [details] [diff] [review]
> patch 0
> 
> Review of attachment 674216 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> r+ with just a minor design detail.
> 
> ::: netwerk/protocol/http/nsHttpConnectionInfo.cpp
> @@ +84,5 @@
> > +        return false;
> > +    const char *proxyType = mProxyInfo->Type();
> > +    if (!proxyType)
> > +        return false;
> > +    if (!strcmp(proxyType, "direct"))
> 
> Since there is a private kProxyType_DIRECT for this literal, I'd rather add
> a new method to nsProxyInfo like bool IsDirect() or so.

I can add the method(s), but kProxyType_DIRECT is defined in nsProtocolProxyService so it will be duplicated. (which I'm fine with - the stirng is defined in the idl).
(In reply to Patrick McManus [:mcmanus] from comment #14)

> I can add the method(s), but kProxyType_DIRECT is defined in
> nsProtocolProxyService so it will be duplicated. (which I'm fine with - the
> stirng is defined in the idl).

Sorry, I didn't see where you were going with this at first. You just want to compare the const static char * ptrs as enums..
Just have bool nsProxyInfo::IsDirect() {return mType = kProxyType_DIRECT;} method somewhere.  You can extern the const somewhere.  The goal is only to keep this encapsulated using the const, nothing more.

But if there are other consumers of nsProxyInfo::Type() that compare to some random strings then we are probably OK with the patch you have, though such API is quit stupid.
https://hg.mozilla.org/mozilla-central/rev/7426b782e0b9

Should this have a test?
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
You need to log in before you can comment on or make changes to this bug.