Networking Release Notes

Java	Networking Release Notes

The following are known bugs and other networking issues for Java^TM 2 SDK, Standard Edition, v1.4.2.

In releases prior to 1.4.2, it was possible to create an invalid URL instance such as the following: new URL ("http://www.foo.com:-1/index.html"). Specifying a port number of -1 is not valid. However, in previous releases the -1 was stripped off when sending such URLS with HTTP commands. In 1.4.2, the -1 is left in the URL and this may cause problems for some HTTP servers or proxies. Applications should not create URL instances with a -1 port number. Assuming the -1 refers to the default port in this example, the correct way to create this URL is new URL ("http://www.foo.com/index.html"). This note only applies to the single argument URL constructor.

On Microsoft Windows 98/ME, a read timeout set using Socket.setSoTimeout or an accept timeout set using ServerSocket.setSoTimeout may result in a timeout that is 500ms later than expected. This issue is observable with all J2SE releases and stems from a Microsoft Windows 98/ME bug. A patch for Microsoft Windows 98/ME is obtainable through the following page on the Microsoft website: http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q257821&

Prior to J2SE 1.4.1 the java.net.InetAddress.getLocalHost() would cache the lookup of the IP address of the local machine for the entire session of the application. This behaviour poses a problem for applications running on machines that are connected to the internet via a dial-up connection or machines that acquired their addresses through DHCP. This has been corrected in 1.4.1 so that the local IP address is no longer cached. InetAddress.getLocalHost() will return the correct IP address for dial-up connections as well as for DHCP. See bug 4211819.

Prior to J2SE 1.4.1, the http/https protocol handlers would not redirect correctly from a http URL to a https URL (and vice versa). In particular, the redirect was attempted using the original URL scheme. This has been fixed in 1.4.1. by returning the server responses for such redirects (from http to https or https to http) to the application. Therefore, it is the applications responsibility to check the response code and recognize it as a redirect. The Location header field value can be checked for the redirect information, and then the application must decide whether or not to follow the redirect using the new protocol. See bug 4620571.

Prior to J2SE 1.4 the java.net.URLConnection class would handle errors from http servers inconsistently. In particular the getInputStream or other methods would throw a FileNotFoundException if the http server returned a response code >= 400 and the request was for a resource of a known file type.
This has been corrected in 1.4 so that an IOException is thrown for any http error from the server and a specific exception of FileNotFoundExeption when the resource is not found (ie: 404 or 410 response codes). The exception is thrown irrespective of the file type.
Applications that assumed an exception would not be thrown when an http error is returned from the server need to be aware of this change in 1.4 - see 4160499.
Related to this issue is that HttpURLConnection.getErrorStream() method can now been used to read the error page from the http server when a http error is returned from the server. Previously getErrorStream() always returned null.

Prior to J2SE 1.4 the InetAddress.toString() would perform a lookup via the name service if the hostname wasn't previously resolved. This is no longer the case in 1.4 and toString will return immediately. If the hostname is not resolved the returned string will contain the dotted IP address only.
Applications that depend on toString() returning a string with the resolved hostname should be aware of this correction in 1.4 - see 4239141.

Prior to J2SE 1.4 if InetAddress.getByName if a lookup to the name service failed then all subsequent lookups of that hostname would fail for the lifetime of the virtual machine. This arose because negative lookups were always cached. This has changed in 1.4 so that by default if a lookup fails it's possible for a subsequent lookup to succeed. This is particularly important in dial-up environments or environments where the name service is not reliable.
Applications that depend on behaviour where subsequent lookups always failed need to be aware of this issue - see 4256129. In addition the caching of negative lookups can be controlled by the networkaddress.cache.negative.ttl property in the java.security file.

Java 2 Platform, Standard Edition, v1.4 introduces a new exception java.net.PortUnreachableException. This exception may be thrown by DatagramSocket.send or DatagramSocket.receive if the DatagramSocket is connected (via the connect method) and an ICMP port unreachable is received to indicate that the remote application is not running. The PortUnreachableException serves as a useful indication for some UDP based protocols.
The following lists the known issues with PortUnreachableException :-
1. On Solaris 8 if IPv6 is enabled then ICMP port unreachable packets from IPv4 hosts will appear to be discarded. This is a Solaris 8 bug and is tracked as bug 4422658.
2. On some Microsoft Windows releases (specifically Windows 98 and Windows NT) ICMP port unreachable packets are incorrectly discarded by the operating system and thus the PortUnreachableException is not thrown. As this time we are not aware of any Windows Sockets updates from Microsoft to fix this issue.
3. On Linux if UDP packets are sent to the loopback address and no UDP applicatiob to bound to the destination port no ICMP port unreachable indication is received and thus no PortUnreachableException is thrown. This is a Linux kernel issue and we are not aware of a patch at this time.

On many Linux installations InetAddress.getLocalHost() may return an InetAddress representing the loopback address (127.0.0.1). This stems from many Linux installations configuring /etc/hosts to map the hostname to the loopback address. If the host has a static IP address then the /etc/hosts file should be corrected to map the hostname to the host address.
If DHCP is used in conjunction with dynamic DNS then there are two options (i) change the name service search order in /etc/nsswitch.conf to use dns before the hosts file (ie: "hosts: dns files"), or (ii) configure InetAddress to use the DNS name service provider instead of the default provider (-Dsun.net.spi.nameservice.provider.1=dns,sun). This issue is being tracked in 4665037.

Sun