Community
Participate
Working Groups
From an e-mail discussion... I got the following error message: Could not connect to :extssh:jervin@proxy.eclipse.org:443/cvsroot/eclipse: CVS communication error: org.eclipse.team.internal.ccvs.ssh2.CVSSSH2ServerConnection$SSH2IOException: ProxyHTTP: java.net.SocketException: Reply from SOCKS server has bad version YMNK said: The message "Reply from SOCKS server has bad version" is not from jsch. I guess that the java system property "socksProxyHost" has been enabled unexpectedly on your environment. Have you used Update Manager or WTP before accessing to CVS? May I ask you to delete settings for SOCKS on the Preferences page, and then try it again? Martin said: Uh-oh. The new Proxy preference page combines Jsch Proxy Preferences with Platform/WTP/Update Proxy Preferences. So if he deletes the Platform Proxy Preferences, they will also be gone for Jsch. I can't currently see how to get around this... doing "socksProxyHost" as a System Property really messes things up. Any ideas? Michael said: I've had a look and it appears that one way to solve this is to use the java.net.Proxy class with a type DIRECT to create the Socket. Unfortunately, we are bound to 1.4 at the moment. Also, the motivation for using the JSch proxy support was to avoid the need to move up to 1.5. Perhaps we can come up with a scheme by which we only set the socks proxy system property if we are using a VM that supports it ( i.e. 1.5 or greater). Unfortunately, we would also need some way for JSch (or CVS) to create a socket that had a DIRECT proxy if the VM was 1.5 or greater (or, we could use the Java Proxy instead of JSch). This later part will be tricky as we would need to have at least some part of CVS dependent on 1.5.
From CVS plug-in point of view, whenever "socksProxyHost" is enabled, all we can do is just to stop to use our own proxy mechanism(from JSch) and hope that JVM's proxy works well. Yes, there must be a timing issues, but almost of all case it must work on JDK 1.4 and Java5.
Actually, I just realized that we should not need to make any changes to make the current support work with 1.4 since the socks properties should just be ignored by Java (i.e. the current support should work fine in 1.4). Hence, what we need to come up with is a mechanism that disables the Java/Net SOCKS proxy when using a JSch Proxy with a 1.5 or later VM.
Created attachment 61013 [details] Here's an updated version of the JSch/Core jar with a fix.
I have released a fix for this to HEAD. I use reflection in the JSch core to disable the Java proxy when creating a JSch proxy. The attached bundle is a fix that can be used with last weeks integration build.
The solution looks good for Java 1.5 - only thing I'm not sure about, is why you think this wouldn't be an issue on a 1.4 JVM. From browsing into the Sun 1.4 Socket source, it seems to me that the disastrous "socksProxyHost" System Property has been there with Java 1.4 already. Unfortunately I have no idea for addressing this, other than setting the System Property to null before creating the Socket in Jsch (should be possible by passing a custom SocketFactory into Jsch) and re-setting it to the previous value immediately after. Neither smart nor robust (since other threads might try creating a Socket at the same time) but failing in some cases is perhaps better than knowing to fail always...
From reading section 2.4 of http://java.sun.com/j2se/1.5.0/docs/guide/net/proxies.html it appears that SOCKS support was only added in 1.5 (or 5.0). Therefore, the properties would just be ignored by a 1.4 JRE. However, my interpretation may be wrong (i.e. it doesn't say it wasn't in 1.4. It just says it's in 5.0). I'll reopen this to investigate further. If 1.4 does indeed support the bad proxy settings, then I think your suggestion will work.
I should add that I agree that this would not be thread safe so I would restrict it to the case where we have a 1.4 VM to ensure it has a minimal impact.
(In reply to comment #5) > Unfortunately I have no idea for addressing this, other than setting the System > Property to null before creating the Socket in Jsch (should be possible by > passing a custom SocketFactory into Jsch) and re-setting it to the previous > value immediately after. Neither smart nor robust (since other threads might > try creating a Socket at the same time) but failing in some cases is perhaps > better than knowing to fail always... I agree with this strategy even if there exists timing issue. # Update manager will need to run for long time to download several jars.... That strategy may be enough for cvs.core point of view, but how about the point of view from the IDE system? If "socksProxyHost" is enabled, every socket programs will not work correctly and every programs including user's programs must do similar hacks. It is a nightmare ;-< # It seems there is not a method to set the non-proxy hosts for SOKCS. IMHO, "socksProxyHost" should not be enabled in org.eclipse.core.net. If plug-ins(Update, WTP, etc.) really need it, they should set "socksPorxyHost" by themself and disable it immediately after getting connections. I really hope they will use java.net.Proxy and stop to use "socksProxyHost" in the near future.
(In reply to comment #8) Hm, I disagree that ensuring the socksProxyHost System Property is empty all the time is the right solution, because 1. socksProxyHost property is a JVM concept in order to provide transparent socket access through a proxy for whatever non-proxy-aware program is running in the JVM. There is a problem only if a program is not using the JVM's proxy support but does it on its own -- like Jsch or apache httpclient. All others should be able to rely on the documented JVM support for pervasive transparent proxy support. Also note that users could set socksProxyHost by vm option outside Eclipse, so how would we get rid of such an externally set property? 2. Because it's a JVM standard, those appliations that do *not* follow the standard must have special handling and not those that do. It looks like with an 1.5 JVM, there is a proper concept for this (Proxy.class / DIRECT). For 1.4, there's the clumsy workaround. Which, IMHO, not only jsch but also Apache httpclient should use until we can use something better. Eclipse. 3. When I'm not mistaken, the Property is only set when user selects "all protocols" in the Proxy Preference page. Which should include those plugins that are not aware of the Preference page but can make use of the JVM's transparent pervasive Proxy support through the Socket class. Adding zx on CC since he contributes httpclient to Orbit, so he might know best where it is used (and can thus argue about adding similar workarounds as for jsch to httpclient as well).
Adding myself to CC. I am using HTTPClient and am about to add the new proxy support of 3.3 M6 to my application. I am suffering from the system property too, since once enabled, the exclusion list is not respected (there does not seem to be a system property for non-proxied-hosts for SOCKS). Just playing with some ideas here, but, if HTTPClient is able to do Proxy programmatically, why do we need to set the proxy system properties at all? I would expect that you could define a proxy without HTTPClient too (but maybe only per Socket?).
(In reply to comment #10) Well that's a good framework question. As the new Proxy Prefs page is generic for all of Eclipse and all extenders, and it has a checkbox "use for all protocols", my personal opinion is that it needs to provide some generic transparent proxy support until all known clients migrate to a method where they can do the proxying on their own. BTW, I noticed that perhaps the threading issues with temporarily resetting the System property on an 1.4 VM can be alleviated since it looks like the Property only needs to be reset while constructing the Socket (then the Socket sets its impl, so the Property can be re-set afterwards and isn't cared for while connecting); and, because it looks like static Socket.checkSocks() is synchronized, it may be possible to do the temporary Property disabling in a synchronized section such that other threads can not be affectect during that time: Socket s; synchronized(Socket.class) { String oldProp = System.getProperty("socksProxyHost"); try { if (oldProp!=null) System.setProperty("socksProxyHost", null); s=new Socket(addr); } finally { if (oldProp!=null) System.setProperty("socksProxyHost", oldProp); } }
(In reply to comment #10) PS from an RCP point of view, perhaps it might be a good idea to be able and tell the Proxy Prefs Page (or whoever sets the system Property) that in the particular application, the SystemProperty should NOT be set and application will be totally responsible itself for doing the Proxy stuff. A Preference setting that's not user-visible but would be affected by a product's plugin_customization.ini might be a good idea for this. The default would be org.eclipse.core.net/SET_GLOBAL_SOCKS_PROXY=true but applications like RSSOwl could do org.eclipse.core.net/SET_GLOBAL_SOCKS_PROXY=false and thus declare that they will care for the proxy themselves.
(In reply to comment #9) > Hm, I disagree that ensuring the socksProxyHost System Property is empty all > the time is the right solution, because > 1. socksProxyHost property is a JVM concept in order to provide transparent > socket access through a proxy for whatever non-proxy-aware program is > running in the JVM. There is a problem only if a program is not using > the JVM's proxy support but does it on its own -- like Jsch or apache > httpclient. I have not cared for jsch anymore, because there exists work around method. I have just really worried about Eclipse SDK platform from user's point of view. Suppose that you are developing program which uses java.net.Socket. During developing phase, you will connecting to hosts on LAN for testing. What will happen if "socksProxyHost" is enabled "unexpectedly"? I hardly believe SOCKS server will usually forward connection requests to destination-host on LAN. If users do not have enough knowledges about "socksProxyHost", they will be confused. Even if they have, they have to disable proxy services explicitly while developing progrmas and for CVS accesses, they have to enable proxy service again, and... This is just my worries. If there is no problem for Eclipse.org, "socksProxyHost" should be enabled all the time. > All others should be able to rely on the documented JVM support for > pervasive transparent proxy support. Also note that users could set > socksProxyHost by vm option outside Eclipse, so how would we get rid > of such an externally set property? If user explicitly set "socksProxyHost", there is no problem, becase it is his/her choice. > 3. When I'm not mistaken, the Property is only set when user selects "all > protocols" in the Proxy Preference page. Which should include those plugins > that are not aware of the Preference page but can make use of the JVM's > transparent pervasive Proxy support through the Socket class. I have enabled that toggle switch, but I can not reproduce that problem; I can get CVS extssh accesses to dev.eclipse.org throught http proxy. I really want to know the reason why "socksProxyHost" has been enabled on his environment.
(In reply to comment #12) > (In reply to comment #10) > PS from an RCP point of view, perhaps it might be a good idea to be able and > tell the Proxy Prefs Page (or whoever sets the system Property) that in the > particular application, the SystemProperty should NOT be set and application > will be totally responsible itself for doing the Proxy stuff. > > A Preference setting that's not user-visible but would be affected by a > product's plugin_customization.ini might be a good idea for this. The default > would be > org.eclipse.core.net/SET_GLOBAL_SOCKS_PROXY=true > but applications like RSSOwl could do > org.eclipse.core.net/SET_GLOBAL_SOCKS_PROXY=false > and thus declare that they will care for the proxy themselves. > Sounds like a good idea, I was thinking about something like that too. Btw, I am a bit confused about Java 1.5: Will the system property not be set if a 1.5+ JVM is being used? I am asking because this was mentioned together with using JSch, however I am not using JSch in my standalone RCP application (its not even part of my target platform).
(In reply to comment #14) > Btw, I am a bit confused about Java 1.5: Will the system property not be set if > a 1.5+ JVM is being used? That system property may be enabled, but we can use java.net.Proxy; new Socket(Proxy.NO_PROXY) on Java5.
(In reply to comment #15) > (In reply to comment #14) > > Btw, I am a bit confused about Java 1.5: Will the system property not be set if > > a 1.5+ JVM is being used? > > That system property may be enabled, but we can use java.net.Proxy; > new Socket(Proxy.NO_PROXY) > on Java5. > > I see. That probablly means to override the default socket factory in HTTPClient.
Created attachment 61079 [details] Patch from Michael V using 1.5 Proxy.class through reflection (In reply to comment #16) Yes. In a way similar to attached patch created by Michael, perhaps with additions for temporary disabling the System Properties for 1.4. Note that the SocketFactory we are using is specific to Jsch and not the javax.net.SocketFactory or org.apache SocketFactory. But you'll see the idea.
(In reply to comment #17) > Created an attachment (id=61079) [details] > Patch from Michael V using 1.5 Proxy.class through reflection > > (In reply to comment #16) > Yes. In a way similar to attached patch created by Michael, perhaps with > additions for temporary disabling the System Properties for 1.4. Note that the > SocketFactory we are using is specific to Jsch and not the > javax.net.SocketFactory or org.apache SocketFactory. But you'll see the idea. > Thanks. We require Java 1.5+ anyways to run, so I think we are fine with overriding the factory. Still, the preferences option for enabling/disabling the properties would be helpful too.
It is clear from the discussion that socks support in 1.4 is broken. Therefore, I think we should detect that we are running a 1.4 VM and, if we are, we should not set the socks system properties at all. If users want to use the Java socks support, they should move up to Java 1.5 (since 1.5 fixes the issue). This would not stop users from specify the properties on the command line so it may be worthwhile to still unset the properties when making JSch connections when using a 1.4 VM. How does this sound?
(In reply to comment #19) > It is clear from the discussion that socks support in 1.4 is broken. Is it really broken? - I'm not so sure. Only thing we know for sure is, that it fails when Jsch tries to talk to a proxy through what it thinks is a direct connection, but turns out the JVM tries and set up as a proxied connection due to system properties. I'm not surprised that the proxy can't talk to itself through itself. As a matter of fact, when I'm not mistaken, update manager and others have been using the System properties for proxy access for quite some time in previous Eclipse versions.
Prior to 3.3, the only plug-in I know of that surfaced the SOCKS proxy was JSch. Update only allowed the user to specify the HTTP proxy. It appears that WTP surface it in Callisto but only as a checkbox (i.e. they had the ability to specify a single proxy server and a checkbox to indicate whether it was a SOCKS proxy). As for being broken, perhaps that is too strong a term. Perhaps a better way to phrase it would be to say that it does not play well with others in 1.4 and therefore we should not let it play. Having a flag that the user must specify on startup is no different from having them explicitly set the properties so that has little benefit over what is proposed in comment 19. Having all other clients override the properties punishes the well behaved clients. As I indicated, JSch and HttpClient may still want to assume the properties may be set but the decision would then be to either override them or throw an exception indicating that the proxy support will not work due to a conflict with the JRE proxy support (or it could override the properties temporarily and log a message indicating that it did so). The bottom line is that I think we need to make the setting of socks system properties when 1.4 is used the exception and not the rule. The proposal in comment 19 does this. If you have an alternate proposal that achieves this, I am happy to hear it.
Very good arguments. Especially that we are talking about a feature that seemingly wasn't there before - I was not aware of that. But with respect to punishing well-behaved clients, don't we also punish them on a 1.5 VM, by requiring them to use a Socket constructor with Proxy/DIRECT? Wouldn't a REALLY well-behaved client have used Proxy/DIRECT even outside Eclipse because anybody can set the System Property? Conceptually, I see no difference between 1.4 and 1.5 with respect to this, except that the method of disabling the VM level proxy is different on 1.4 and 1.5. It's not as clean on 1.4 but with the code from comment 11 it may even be thread-safe. Or almost thread-safe, since it looks like ServerSocket also accesses the Property, but most access are in Socket and guarded by the synchronized lock. So if users could select the Socks proxy "for all protocols" but it would not actually be executed on a 1.4 VM, how does that relate to your bug 154100 comment 111 where you say "If we add (the domain) to the general data, users may be confused about when it gets used and when it doesn't"?
The difference between the 1.4 punishment and the 1.5 punishment is that the 1.5 punishment is part of the spec. The workaround for 1.4 that you are proposing is not part of the spec. So, although it may work for the VMs from a particular vendor, it is not guaranteed to work with all VMs. As for my comment in bug 154100 regarding domains, it turns out I was wrong. This is supported by Java as either a system property or it can be encoded in the user name. Since we are too close to the API deadline, we'll need to settle with encoding the NT domain in the user name for 3.3.
Btw after a quick look at the API of Socket, it doesn't seem as if you could set the proxy from anywhere else than the constructor, which is a problem because the socket factory in HTTPClient makes use of different constructors. Users of HTTPClient might have to go for the 1.4 approach (temp. unsetting system properties).
(In reply to comment #23) > The difference between the 1.4 punishment and the 1.5 punishment is that the > 1.5 punishment is part of the spec. Hm.. good point. While the System Properties themselves are documented and can be reset temporarily as part of teh spec, there is no real guarantee that it's sufficient to set/re-set the system properties around the constructor, and that a synchronized block around Socket.class is helpful. But in reality, I checked the IBM 1.4.2 and BEA JRockit 1.4 JDKs, and they both have licensed the source from Sun apparently, which makes the workaround from comment 11 good for the Sun, IBM and BEA JVMs. Which is all the 1.4 JVMs I know about that are able to run Eclipse. I don't know about how far Harmony and GCJ are for running Eclipse, and what fraction of the market that would be. Anyways, I've heard that 1.4 is EOLd from sun this summer, so perhaps we should not worry too much about the missing feature when the System Properties are not set.
For M6, I have disabled the setting of the system properties if a 1.4 VM is being used (and I log a message indicating that upgrading to 1.5 will allow the properties to be set). I don't view this as a final solution but I think it is acceptable for M6. In M7, we will try and work out what the final answer for 3.3 will be.
(In reply to comment #13) > I have enabled that toggle switch, but I can not reproduce that problem; > I can get CVS extssh accesses to dev.eclipse.org throught http proxy. > I really want to know the reason why "socksProxyHost" has been enabled on his > environment. I found the reason why I did not have that problem! My http proxy is running at 127.0.0.1:8888 and I have checked "Use this proxy server...". So, I have confirmed "socksProxyHost" has "127.0.0.1" on Help > About Eclipse SDK > Configuration Details . But, I could accesses to dev.eclipse.org with CVS extssh. # On my environment, 127.0.0.1:8888 will be forward to http proxy server, # which is running in my office. Next, I have changed the proxy setting to 192.168.0.1:8888, where 192.168.0.1 is ip-address of my client machine. With this setting, I could not get accesses. If I delete the setting on SOCKS proxy field, I could get CVS accesses, of course. Today's tips socksProxyHost=127.0.0.1 does not work, but socksProxyHost=localhost, socksProxyHost="client's ip-address" are functional.
(In reply to comment #25) > I don't know about how far Harmony and GCJ are for running Eclipse, and what > fraction of the market that would be. FYI, it seems to me that GCJ on Fedora Core 5, % java -version java version "1.4.2" gij (GNU libgcj) version 4.1.1 20060525 (Red Hat 4.1.1-1) does not support "socksProxyHost" property and I have checked the source code of GNU classpath, but I can not find the method static Socket.checkSocks() You have used the term "documented". In the Java context, that must mean that "socksProxyHost" has been formally defined on JLS,JSR. May I ask you a pointer, which document has "formally" defined it? For long time, I had believed that it is just a local hack by Sun, so I had choosed to implement our own proxy mechanism in JSch. If it is really "documented", GCJ will support it in the near future and I can expect it on every Java platform and think of stopping to use our own proxy mechanism. Thank you for good news! I'll wait for your pointer.
I have confirmed that Michael's reflection patch for org.eclipse.jsch.core will really work well and we can get CVS extssh accesses through http proxy even if "socksProxyHost" is enabled. Now, that system property is not problematic for CVS plug-in on Java5 at least.
I confirmed that CVS pserver and pserverssh2 will work by using the latest org.eclipse.jsch.core plug-in even if "socksProxyHost" is enabled. Please note that for the connection type "pserverssh2" "127.0.0.1" must be listed in "No Proxy for:" on the preference page, because it needs to make pserver accesses to 127.0.0.1 and it will be forwared to the remote pserver by using ssh2's local port forwarding.
Tips: On Sun's j2sdk 1.4.*, whenever "socksProxyHost" is enabled, every TCP connections will be forwared to the socks server, but on Sun's Java5 environment even if "socksProxyHost" is enabled, TCP accesess to "127.0.0.1" and "localhost" will not be forwared to. I have not checked about other referenced platforms: IBM's JDK, JRockit,etc. This means that if "127.0.0.1" is not listed in "No Proxy for:" on the Preference page or other hosts are inclued there, warning messages should be appeared in somewhere, because it is unknown how to set no-porxy for socks. One more comment. The success of CVS pserverssh2 in comment #30 heavily depends on that Java5's ad hoc behavior. In that case, "127.0.0.1" is listed in "No Proxy for:". This means that Michael's refection patch will not be used in CVS pserver and java.net.Socket without Proxy.NO_PROXY will be used to get accesses to "127.0.0.1". If java5(or 6) changes its behavior suddenly, it will break down.
(In reply to comment #28) > FYI, it seems to me that GCJ on Fedora Core 5, > does not support "socksProxyHost" property and > I have checked the source code of GNU classpath, but I can not find > the method "static Socket.checkSocks()" checkSocks() is package private and thus an implementation detail. It would be more interesting to read the source code behind the Socket(..) constructors, and what happens on Socket.connect(). Does the gcj classlib also have a notion of SocketImpl and SocketImplFactory? I guess it must, since these are API. If it does, what known subclasses are there of SocketImpl and SocketImplFactory? In the JDK, there are (package private, again) class SocksSocketImpl and class SocksSocketImplFactory. > You have used the term "documented". In the Java context, that must mean that > "socksProxyHost" has been formally defined on JLS,JSR. May I ask you a > pointer, which document has "formally" defined it? I'm not sure if this is formal enough, but the JDK 1.4 Language Guide has http://java.sun.com/j2se/1.4.2/docs/guide/net/properties.html Java5 went beyond that, and also has http://java.sun.com/j2se/1.5.0/docs/guide/net/proxies.html Note the interesting text right after the heading of section 2: "The major limitation of using system properties is that they are an “all or nothing” switch. Meaning that once a proxy has been set for a particular protocol, it will affect all connections for that protocol. It's a VM wide behavior." I would add to this, the biggest implication of that limitation is, that it doesn't have an "exclude" list for addresses to proxy. I guess that this is one of the main reasons why some libraries went and did their own Proxy support. I think that because of these limitations, the "System Property" kind of supporting proxies should really be deprecated and the Java 5 "Proxy" class should be used instead (sections 3, 4 of the document mentioned above). Pondering this again, I guess that the idea of a transparent, system-wide proxy is not a very good one, especially when it is not possible to exclude addresses from proxying. I think that if we can, we should avoid setting the socksProxyHost System Property at all (not only for Java1.4 as Michael already did, but also for Java5). Punishing well-behaved clients is really problematic. Each library should responsible for doing Proxy support itself, perhaps with the help of some common utility classes. If an Eclipse user really really needs the Proxy System Properties, he could still set it on the commandline with -DsocksProxyHost=xxx (In reply to comment #31) > I have not checked about other referenced platforms: IBM's JDK, JRockit,etc. It looks like IBM and JRockit have licensed the Classlib sources from sun, so they will all be the same except for native implementations.
(In reply to comment #32) > Pondering this again, I guess that the idea of a transparent, system-wide proxy > is not a very good one, especially when it is not possible to exclude addresses > from proxying. I think that if we can, we should avoid setting the > socksProxyHost System Property at all (not only for Java1.4 as Michael already > did, but also for Java5). Punishing well-behaved clients is really problematic. > Each library should responsible for doing Proxy support itself, perhaps with > the help of some common utility classes. If an Eclipse user really really needs > the Proxy System Properties, he could still set it on the commandline with > -DsocksProxyHost=xxx Yep, I like this solution (as I mentioned earlier, it does not seem to be easy to define Proxy use on Socket level for httpclient).
The decision to enable that system property has been done. I have respected for that decision. So, my current interests are to learn how to survive or coexist with that property. To survive, we need to understand what kind of problems will occur on Eclipse SDK 3.3 and what we can do for that. If it is impossible to resolve some problems, there should be documentations for them. But, almost of all including me have been talking about that property based on a few lines explanations from Sun and it is hardly enough. This is the motivation for my recent some posts. On the other hand, I have still a hope for the possibility of changing the behavior of the checkbox "Use this proxy server for all protocols" on the preference page. IMHO, it is not reasonable to set the "SOCKS proxy" filed by that switch. In fact, you know that IE on Windows will not set SOCKS field by such a toggle switch. Almost of users who are not behind SOCKS firewall must not expect that "socksProxyHost" is enabled all the time by that switch.
There seem to be a few problems mentioned in the comments added since my last comment. To be honest, I find it hard to figure out which problems should be addressed by this bug and which are separate issues. To deal with this, I think the best approach is to limit this bug to dealing with when we should set the SOCKS system properties. Any other problems (e.g. problems that occur when the SOCKS system properties are set or enhancements to the preference page) should be logged in separate bug reports. After some thought, I am going to close this bug as fixed. My reasoning is this. In Java 1.4, setting the SOCKS system properties is problematic since there is no way (short of unsetting the properties) of making a TCP connection that does not use the SOCKS proxy. In Java 1.5 this has been fixed. I understand that some libraries, like httpClient, may not make use of this 1.5 API when they use their own proxy but, to me, this means that the library is not 1.5 compatible. I understand the desire to avoid setting the properties altogether. However, this shifts the responsibility of managing the SOCKS proxy settings from the developer to the user. I do not believe that the average user would understand the difference between a SOCKS proxy that uses the Java libraries vs. one that uses JSch or httpClient. From the user standpoint, they just want to set the SOCKS proxy and have it work for all instances where it applies. If the user is using a 1.4 VM, I think it is acceptable to tell them to upgrade to a 1.5 VM or later. Once they upgrade to 1.5, I think it is up to the developer to ensure that SOCKS proxies work properly. I do not believe that any of the other possible approaches outlined in the previous comments would be acceptable from a user standpoint.
FYI, bug 181655 is an yet another problem, which has been caused by "socksProxyHost".
