United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4245722 Socket(String, int) should call SocketImpl.connect(String, int)
JDK-4245722 : Socket(String, int) should call SocketImpl.connect(String, int)

Details
Type:
Bug
Submit Date:
1999-06-10
Status:
Resolved
Updated Date:
2001-03-10
Project Name:
JDK
Resolved Date:
2001-03-10
Component:
core-libs
OS:
solaris_2.5
Sub-Component:
java.net
CPU:
sparc
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.2.0
Fixed Versions:
1.4.0 (beta)

Related Reports
Relates:

Sub Tasks

Description
I wrote the beginnings of a SocketImplFactory that would allow transparent
access from inside Sun's firewall to machines both inside 
and outside that firewall.  By installing a SocketImplFactory that intercepts 
the hostnames, checks to see if they are local (within the Sun firewall) or 
remote, I can either make a socket to the local machine or connect to the 
firewall and perform some handshaking with 
it to get it to give me a socket to a remote machine.

Unfortunately, there is a "bug" in Socket(String hostname, int port) that
will prevent this from working.  The first thing that Socket(String, int)
does with the hostname is convert it into an InetAddress and then tell the
SocketImpl to connect to the given InetAddress.  So my SocketImpl will
never get the remote hostname and a chance to parse it and redirect the
connect outside the firewall; the constructor for Socket will have already
failed with an UnknownHostException because hostnames outside of the
firewall cannot be mapped to InetAddresses.

Instead: Socket(String, int) should call SocketImpl.connect(String, int)

otherwise, this renders SocketImplFactories useless for going through firewalls to machines whose IP address is not known within the firewall.  It is ironic, since the comments in SocketImpl.java state that the "impl" way of doing things was done to make it possible to do things like tunnel through firewalls.

                                    

Comments
EVALUATION

Yes, the Socket implementation assumed that all addresses should be resolved
at connect time. Of course, this is not quite the case, for instance with
a SOCKS v5 proxy you can delegate the name resolution to the proxy.

In 1.4 there is a new class, SocketAddress, that is used for connect & bind
calls. A SocketAddress can be unresolved and the new SOCKS implementation can
deal with unresolved addresses. However the old Socket constructors are still
trying to resolve the hostname into an InetAddress before calling connect,
which defeats the purpose of using SocketAddress. This need to be changed.

Note that in Merlin SocketImpl.connect(String, int) &
SocketImpl.connect(InetAddress, int) are kind of deprecated as only
SocketImpl.connect(SocketAddress, int) is called.

jean-christophe.collet@Eng 2001-02-23
                                     
2001-02-23
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
merlin-beta

FIXED IN:
merlin-beta

INTEGRATED IN:
merlin-beta


                                     
2004-06-14



Hardware and Software, Engineered to Work Together