ネットワーク機能リリース・ノート
- 1.4.2より前のリリースでは、
new URL ("http: //www.example.com:-1/index.html")のような無効なURLインスタンスを作成できました。ポート番号に-1を指定することは有効ではありません。しかし、以前のリリースでは、このようなURLをHTTPコマンドで送信する際に、-1が削除されていました。1.4.2では、-1がURLに残るため、一部のHTTPサーバーやプロキシで問題となる可能性があります。アプリケーションでポート番号が-1のURLインスタンスを作成しないでください。この例では、-1はデフォルト・ポートを参照すると仮定していますが、このURLを作成するには、new URL ("http://www.example.com/index.html")が正しい方法です。この注意は、単一の引数によるURLコンストラクタにだけ適用されます。
- Microsoft Windows 98/MEでは、Socket.setSoTimeoutを使用して設定した読取りタイム・アウトや、ServerSocket.setSoTimeoutを使用して設定した受け入れタイム・アウトでは、想定よりも500ミリ秒後にタイム・アウトになる場合があります。この問題はすべてのJava SEリリースで発生しますが、Microsoft Windows 98/MEの不具合が原因です。Microsoft Windows 98/ME用のパッチは、Microsoft Webサイトのhttp: //support.microsoft.com/default.aspx?scid=KB;EN-US;Q257821&から入手できます。
- Java SE 1.4.1より前では、java.net.InetAddress.getLocalHost()は、アプリケーションのセッション全体で、ローカル・マシンのIPアドレスの検索内容をキャッシュしていました。この動作では、ダイアル・アップ接続でインターネットに接続しているマシン上や、DHCPでアドレスを取得したマシン上で実行しているアプリケーションでは問題が発生します。これは1.4.1で修正され、ローカルIPアドレスはキャッシュされなくなりました。InetAddress.getLocalHost()で、ダイアル・アップ接続やDHCPの場合の正しいIPアドレスが返されます。バグ4211819を参照してください。
- Java SE 1.4.1より前では、http/httpsプロトコル・ハンドラは、http URLからhttps URLへの(およびその逆の)リダイレクトを正しく行っていませんでした。特に、元のURLスキームを使用してリダイレクトしようとしていました。1.4.1では、そのようなリダイレクト(httpからhttps、またはhttpsからhttp)に対するサーバー応答をアプリケーションに返すことで、この問題を修正しました。そのため、アプリケーションで、応答コードを確認し、そのコードがリダイレクトであることを識別しなければなりません。Locationヘッダー・フィールド値はリダイレクト情報としてチェック可能であるため、アプリケーションは新しいプロトコルを使用してリダイレクトを行うかどうかを決定する必要があります。バグ4620571を参照してください。
- Java SE 1.4より前、java.net.URLConnectionクラスでは、httpサーバーからのエラーを一貫性なく処理していました。実際に、getInputStreamやその他のメソッドでは、httpサーバーが400以上の応答コードを返す場合で、かつ要求が既知のファイル・タイプのリソースに関するものである場合は、FileNotFoundExceptionをスローしていました。
1.4では修正され、サーバーからのhttpエラーではすべてIOExceptionがスローされ、リソースが見つからないとき(つまり、応答コードが404または410の場合)に、専用の例外FileNotFoundExeptionをスローします。この例外は、ファイル・タイプに関係なくスローされます。
アプリケーションで、サーバーからhttpエラーが返されたときに例外がスローされないことを想定していた場合、そのようなアプリケーションは1.4でのこの変更を認識する必要があります。4160499を参照してください。
この問題に関連して、httpエラーがサーバーから返されたときにhttpサーバーからエラー・ページを読み取るために、HttpURLConnection.getErrorStream()メソッドを使えるようになりました。これまでのgetErrorStream()は、常にnullを返していました。
- Java SE 1.4より前は、InetAddress.toString()では、ホスト名がこれまで解決されていなかった場合に、ネーム・サービスを介して検索を実行していました。1.4では変更され、toStringはすぐに返されます。ホスト名が解決されない場合、返される文字列には、ドットで区切られた形式のIPアドレスだけが含まれます。
アプリケーションで、toString()が解決されたホスト名の文字列を返すことを前提としている場合、1.4でこの変更がなされたことに注意してください。4239141を参照してください。
- Java SE 1.4より前では、InetAddress.getByNameでネーム・サービスに対する検索に失敗した場合、仮想マシンのライフ・タイム中は、そのホスト名に関する後続の検索すべてが失敗します。これは、ネガティブ検索が常にキャッシュされていたためです。1.4ではデフォルトで、検索に失敗した場合でも、後続の検索は成功する可能性があるように変更されました。これは、ダイアル・アップ環境や、ネーム・サービスの信頼性が低い環境では特に重要です。
後続の検索が常に失敗するという動作を前提としたアプリケーションでは、この問題に注意する必要があります。4256129を参照してください。また、ネガティブ検索をキャッシュするかどうかは、java.securityファイルのnetworkaddress.cache.negative.ttlプロパティで制御できます。
- Java SE 1.4では、新しい例外java.net.PortUnreachableExceptionが導入されました。この例外は、DatagramSocketがconnectメソッドを介して接続していて、かつリモート・アプリケーションが実行中でないことを示すICMPポート到達不能を受信した場合、DatagramSocket.sendまたはDatagramSocket.receiveによってスローされる可能性があります。PortUnreachableExceptionは、UDPベース・プロトコルの種類によっては便利な表示となります。
PortUnreachableExceptionに関する既知の問題を次に示します。
- Solaris 8ではIPv6が有効な場合、IPv4ホストからのICMPポート到達不能パケットは廃棄されたようにみえます。これはSolaris 8のバグであり、バグ番号4422658として確認できます。
- 一部のMicrosoft Windowsリリース(特にWindows 98とWindows NT)では、ICMPポート到達不能パケットは、オペレーティング・システムによって不適切に破棄されてしまうため、PortUnreachableExceptionがスローされません。現時点では、この問題を修正するためのWindows Sockets更新がMicrosoftからリリースされたことを確認していません。
- LinuxではUDPパケットがループバック・アドレスに送信され、宛先ポートにバインドされたUDPアプリケーションがない場合は、ICMPポート到達不能通知を受信しないため、PortUnreachableExceptionはスローされません。これはLinuxカーネルの問題であり、現時点ではパッチが提供されていることを確認していません。
- 多くのLinuxインストールで、InetAddress.getLocalHost()はループバック・アドレス(127.0.0.1)を示すInetAddressを返すことがあります。これは、多くのLinuxインストールで、ホスト名をループバック・アドレスにマップするように/etc/hostsを構成しているのが原因です。ホストが静的IPアドレスを使用している場合は、ホスト名をホストのアドレスにマップするように、/etc/hostsファイルを修正してください。
DHCPと動的DNSを併用している場合は、2つのオプションがあります。(i) /etc/nsswitch.confでネーム・サービスの検索順序を変更し、hostsファイル(「hosts: DNSファイル」)の前にDNSを使用してください。または(ii)デフォルトのプロバイダの代わりにDNSネーム・サービス・プロバイダを使用するように、InetAddressを構成してください(-Dsun.net.spi.nameservice.provider.1=dns,sun)。この問題は4665037で確認できます。