J2SE Version (please include all output from java -version flag):
  java version "1.6.0_01-ea"
  Java(TM) SE Runtime Environment (build 1.6.0_01-ea-b02)
  Java HotSpot(TM) Client VM (build 1.6.0_01-ea-b02, mixed mode, sharing)


Does this problem occur on J2SE 1.4.x or 5.0.x ?  Yes / No (pick one)
  Not really! It can happen but probably won't in realistic scenarios. stated below


Operating System Configuration Information (be specific):
  Windows XP PRO SP2
  IE 7.0
  Firefox 2.0.0.1

Hardware Configuration Information (be specific):
   customer  VIAO laptop 2.8 Gz
  1.25 GB RAM


Bug Description:

Using the default mechanisms in  customer 's HttpClient, I get the error: "Reply from SOCKS server has bad version".  Strangely, this does not cause a problem when using HttpURLConnection.

Upon investigation, it looks like HttpURLConnection eventually gets its sockets from sun.net.NetworkClient.  This does not use the socket factories, but uses:
protected Socket doConnect (String server, int port) which creates sockets via new Socket(...).  This may explain why HttpURLConnection does not get the error as socket created using the java.net.SocketFactory.

Looking a bit deeper into browser behavior:
-------------------------------------------

In FireFox, setting the proxy once and then checking the "Use this proxy server for all protocols" sets the SOCKS proxy and causes this test case to fail.  
In IE, checking the analogous box actually *clears* the SOCKS check box.
In either browser, if the SOCKS proxy is turned on and filled out, webstart will fail with this test.

I am not sure where the fault lies, in Java's interpretation of this, or in Firefox not clearing this field.  Either way, I can foresee problems for us and for Java on the Horizon.  As people start using Firefox and run programs that use the java.net.SocketFactory, problems are going to crop up causing their applications to be unusable.

Webstart Console
---------------------
Java Web Start 1.6.0_01-ea
Using JRE version 1.6.0_01-ea Java HotSpot(TM) Client VM
User home directory = C:\Documents and Settings\mac
----------------------------------------------------
c:   clear console window
f:   finalize objects on finalization queue
g:   garbage collect
h:   display this help message
m:   print memory usage
o:   trigger logging
p:   reload proxy configuration
q:   hide console
r:   reload policy configuration
s:   dump system and deployment properties
t:   dump thread list
v:   dump thread stack
0-5: set trace level to <n>
----------------------------------------------------
HTTP @ /192.9.201.252:8080
-------------------------------------------------------
Using wrapped java.net socket factory
-------------------------------------------------------
Jan 19, 2007 9:51:47 AM org. customer .commons.httpclient.HttpMethodDirector executeWithRetry
INFO: I/O exception (java.net.SocketException) caught when processing request: Reply from SOCKS server has bad version
Jan 19, 2007 9:51:47 AM org. customer .commons.httpclient.HttpMethodDirector executeWithRetry
INFO: Retrying request
Jan 19, 2007 9:51:47 AM org. customer .commons.httpclient.HttpMethodDirector executeWithRetry
INFO: I/O exception (java.net.SocketException) caught when processing request: Reply from SOCKS server has bad version
Jan 19, 2007 9:51:47 AM org. customer .commons.httpclient.HttpMethodDirector executeWithRetry
INFO: Retrying request
Jan 19, 2007 9:51:47 AM org. customer .commons.httpclient.HttpMethodDirector executeWithRetry
INFO: I/O exception (java.net.SocketException) caught when processing request: Reply from SOCKS server has bad version
Jan 19, 2007 9:51:47 AM org. customer .commons.httpclient.HttpMethodDirector executeWithRetry
INFO: Retrying request
java.net.SocketException: Reply from SOCKS server has bad version
	at java.net.SocksSocketImpl.connectV4(Unknown Source)
	at java.net.SocksSocketImpl.connect(Unknown Source)
	at java.net.Socket.connect(Unknown Source)
	at java.net.Socket.connect(Unknown Source)
	at java.net.Socket.<init>(Unknown Source)
	at java.net.Socket.<init>(Unknown Source)
	at javax.net.DefaultSocketFactory.createSocket(Unknown Source)
	at proxytest.SocketFactoryWrapper.createSocket(SocketFactoryWrapper.java:47)
	at org. customer .commons.httpclient.HttpConnection.open(Unknown Source)
	at org. customer .commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(Unknown Source)
	at org. customer .commons.httpclient.HttpMethodDirector.executeWithRetry(Unknown Source)
	at org. customer .commons.httpclient.HttpMethodDirector.executeMethod(Unknown Source)
	at org. customer .commons.httpclient.HttpClient.executeMethod(Unknown Source)
	at org. customer .commons.httpclient.HttpClient.executeMethod(Unknown Source)
	at proxytest.Main.bar(Main.java:95)
	at proxytest.Main.foo(Main.java:60)
	at proxytest.Main.main(Main.java:50)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at com.sun.javaws.Launcher.executeApplication(Unknown Source)
	at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
	at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
	at com.sun.javaws.Launcher.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
-------------------------------------------------------
Using HttpClient default socket factory
-------------------------------------------------------
Jan 19, 2007 9:51:47 AM org. customer .commons.httpclient.HttpMethodDirector executeWithRetry
INFO: I/O exception (java.net.SocketException) caught when processing request: Reply from SOCKS server has bad version
Jan 19, 2007 9:51:47 AM org. customer .commons.httpclient.HttpMethodDirector executeWithRetry
INFO: Retrying request
Jan 19, 2007 9:51:47 AM org. customer .commons.httpclient.HttpMethodDirector executeWithRetry
INFO: I/O exception (java.net.SocketException) caught when processing request: Reply from SOCKS server has bad version
Jan 19, 2007 9:51:47 AM org. customer .commons.httpclient.HttpMethodDirector executeWithRetry
INFO: Retrying request
Jan 19, 2007 9:51:47 AM org. customer .commons.httpclient.HttpMethodDirector executeWithRetry
INFO: I/O exception (java.net.SocketException) caught when processing request: Reply from SOCKS server has bad version
Jan 19, 2007 9:51:47 AM org. customer .commons.httpclient.HttpMethodDirector executeWithRetry
INFO: Retrying request
java.net.SocketException: Reply from SOCKS server has bad version
	at java.net.SocksSocketImpl.connectV4(Unknown Source)
	at java.net.SocksSocketImpl.connect(Unknown Source)
	at java.net.Socket.connect(Unknown Source)
	at java.net.Socket.connect(Unknown Source)
	at java.net.Socket.<init>(Unknown Source)
	at java.net.Socket.<init>(Unknown Source)
	at javax.net.DefaultSocketFactory.createSocket(Unknown Source)
	at proxytest.SocketFactoryWrapper.createSocket(SocketFactoryWrapper.java:47)
	at org. customer .commons.httpclient.HttpConnection.open(Unknown Source)
	at org. customer .commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(Unknown Source)
	at org. customer .commons.httpclient.HttpMethodDirector.executeWithRetry(Unknown Source)
	at org. customer .commons.httpclient.HttpMethodDirector.executeMethod(Unknown Source)
	at org. customer .commons.httpclient.HttpClient.executeMethod(Unknown Source)
	at org. customer .commons.httpclient.HttpClient.executeMethod(Unknown Source)
	at proxytest.Main.bar(Main.java:95)
	at proxytest.Main.foo(Main.java:61)
	at proxytest.Main.main(Main.java:50)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at com.sun.javaws.Launcher.executeApplication(Unknown Source)
	at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
	at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
	at com.sun.javaws.Launcher.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
Success HttpURLConnection

Webstart 5.0 reads its proxy settings from IE *always*, whether or not it is
the default.  Because of this, the behavior of the IE (to clear this field)
prevents this issue from happening.  Webstart 6.0 checks the default
browser's settings.  If the default browser is Firefox, which does not clear
the SOCKS proxy setting, connections will fail.

This revelation makes this more of a 6.0 issue in that applications are
going to stop working for people.  I don't think that this is really
webstart's "fault", but users that have problems are just going to know it
worked under 5.0 and not under 6.0.  I trust that you will also see the
potential impact of this issue.  Just like Sun was forced to fix the DirectX
frame buffer thing with ATI laptop video cards, you will probably have to
address this in some way.
Posted Date : 2007-01-19 18:22:19.0

N/A

This isn't looking like a bug in Java Webstart, instead it maybe an issue in J2SE network area or org.apache.*, I am reassign it to network team for future evaluation.

I looked at Firefox 1.5, it has the same behavior for setting up proxy as in Firefox 2.0.
Posted Date : 2007-02-13 20:42:12.0

I have spent most of today sitting with 2 Windows XP boxes using Firefox for webstart. One exhibits this issue, one does not. We have checked Java versions, browser versions, network setups etc. and cannot find the difference between the two.

I have spent most of today sitting with 2 Windows XP boxes using Firefox for webstart. One exhibits this issue, one does not. We have checked Java versions, browser versions, network setups etc. and cannot find the difference between the two.

On XP with IE 6 & 7 and Java 6, the default configuration, when specifying a proxy in IE, enables "Use the same proxy server for all protocols." Differing from the bug description above, this setting in IE doesn't mean SOCKS. In fact, the SOCKS text field is blanked out. However, when using "java.net.useSystemProxies=true" all outbound Sockets try to use SOCKS. IE, of course doesn't try to use SOCKS. So, my users can see a site in IE just fine, but my application can't see it. I've had to instruct all of my clients to go in and manually un-check "Use the same proxy for all protocols" on all of the systems that run my app and that fixes the issue, but it seems that "java.net.useSystemProxies=true" is not compatible with IEs settings. Instead, Java shouldn't use SOCKS when IE has a proxy configured to "Use the same proxy server for all protocols."