790321 - Firefox fails to recover after temporary proxy disconnect (SOCKS)

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Thomas Dwyer III]

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.

Comment 1

[Masatoshi Kimura [:emk]]

I think this is a regression of bug 641937.

Comment 2

[Masatoshi Kimura [:emk]]

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)?

Comment 3

[Thomas Dwyer III]

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...)

Comment 4

[Matthias Versen [:Matti]]

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.

Comment 5

[Thomas Dwyer III]

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.

Comment 6

[Patrick McManus [:mcmanus]]

regression keyword from comment 1 ruled out by comment 3

Comment 7

[Patrick McManus [:mcmanus]]

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

Comment 8

[bjoern]

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.

Comment 9

[bjoern]

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.

Comment 10

[Patrick McManus [:mcmanus]]

bjoern did you only see this when using a proxy? I think I can see why that might have been a problem

Comment 11

[bjoern]

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.

Comment 12

[Patrick McManus [:mcmanus]]

Attachment: patch 0

HTTP proxies were excluded from coalescing logic, but SOCKS proxy were not.

Comment 13

[Honza Bambas (:mayhemer)]

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.

Comment 14

[Patrick McManus [:mcmanus]]

(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).

Comment 15

[Patrick McManus [:mcmanus]]

(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..

Comment 16

[Honza Bambas (:mayhemer)]

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.

Comment 17

[Patrick McManus [:mcmanus]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/7426b782e0b9

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/7426b782e0b9

Should this have a test?