Сети Информации о версии

Следующее является известными ошибками и другими сетевыми проблемами для ^JavaTM 2 SDK, Standard Edition, v1.4.2.

В выпусках до 1.4.2, было возможно создать недопустимый экземпляр URL, такой как следующее: new URL ("http://www.example.com:-1/index.html"). Определение номера порта -1 не допустимо. Однако, в предыдущих выпусках -1 был неизолированным, отправляя такие URL с командами HTTP. В 1.4.2, -1 оставляется в URL, и это может вызвать проблемы для некоторых серверов HTTP или прокси. Приложения не должны создать экземпляры URL с a -1 номер порта. Принятие -1 обращается к порту значения по умолчанию в этом примере, корректный способ создать этот URL new URL ("http://www.example.com/index.html"). Это примечание только применяется к единственному параметру конструктор URL.

На Microsoft Windows, 98/ME, набор тайм-аута чтения, используя Socket.setSoTimeout или принять набор тайм-аута, используя ServerSocket.setSoTimeout может привести к тайм-ауту, который является на 500 мс позже чем ожидаемый. Эта проблема заметна со всеми выпусками J2SE и основами от Microsoft Windows ошибка 98/ME. Патч для Microsoft Windows, 98/ME, доступен через следующую страницу на веб-сайте Microsoft: http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q257821&

До J2SE 1.4.1 java.net.InetAddress.getLocalHost() кэшировал бы поиск IP-адреса локальной машины для всего сеанса приложения. Это поведение излагает проблему приложениям, работающим на машинах, которые соединяются с Интернетом через телефонную связь через модем или машины, которые получали их адреса через DHCP. Это было исправлено в 1.4.1 так, чтобы локальный IP-адрес больше не кэшировался. InetAddress.getLocalHost() возвратит корректный IP-адрес для телефонных связей через модем так же как для DHCP. См. ошибку 4211819.

До J2SE 1.4.1, http/https обработчики протокола не перенаправили бы правильно от http URL до https URL (и наоборот). В частности перенаправление было предпринято, используя исходную схему URL. Это было фиксировано в 1.4.1. возвращая ответы сервера для таких перенаправлений (от http до https или https к http) к приложению. Поэтому, это - обязанность за приложения проверить, что ответ кодирует и распознает это как перенаправление. Значение поля заголовка Расположения может быть проверено на информацию о перенаправлении, и затем приложение должно решить, следовать ли за перенаправлением, используя новый протокол. См. ошибку 4620571.

До J2SE 1.4 java.net.URLConnection class обработал бы ошибки от http серверов несовместимо. В особенности getInputStream или другие методы бросили бы FileNotFoundException, если бы http сервер, возвращенный код ответа> = 400 и запрос, был для ресурса известного типа файла.
Это было исправлено в 1.4 так, чтобы IOException был брошен для любой http ошибки от сервера и определенного исключения FileNotFoundExeption, когда ресурс не находится (то есть: 404 или 410 кодов ответа). Исключение выдается независимо от типа файла.

Приложения, которые принимали исключение, не будут брошены, когда http ошибка будет возвращена из сервера, должен знать об этом изменении в 1.4 - см. 4160499.

Связанный с этой проблемой то, что метод HttpURLConnection.getErrorStream() может теперь, имел обыкновение читать ошибочную страницу из http сервера, когда http ошибка возвращается из сервера. Ранее getErrorStream() всегда возвращаемый null.

До J2SE 1.4 InetAddress.toString() выполнил бы поиск через службу имен, если бы имя узла не было ранее разрешено. Это больше не имеет место в 1.4, и toString сразу возвратится. Если имя узла не будет разрешено, то возвращенная строка будет содержать точечный IP-адрес только.
Приложения, которые зависят от toString(), возвращая строку с разрешенным именем узла, должны знать об этом исправлении в 1.4 - см. 4239141.

До J2SE 1.4, если InetAddress.getByName, если бы поиск к службе имен, отказавшей тогда, все последующие поиски того имени узла перестали бы работать для времени жизни виртуальной машины. Это возникло, потому что отрицательные поиски всегда кэшировались. Это изменилось в 1.4 так, чтобы по умолчанию, если поиск перестал работать, для последующего поиска было возможно успешно выполниться. Это особенно важно в коммутируемых средах или средах, где служба имен не надежна.
Приложения, которые зависят от поведения, где последующие поиски всегда отказавшая потребность знать об этой проблеме - см. 4256129. Кроме того, кэшированием отрицательных поисков может управлять свойство networkaddress.cache.negative.ttl в файле java.security.

Java 2 Платформы, Standard Edition, v1.4 представляют новое исключение java.net.PortUnreachableException. Это исключение может быть выдано DatagramSocket.send или DatagramSocket.receive, если DatagramSocket соединяется (через соединить метод), и недостижимый порт ICMP получается, чтобы указать, что удаленное приложение не работает. PortUnreachableException служит полезной индикацией для некоторого UDP базируемые протоколы.
Следующие списки известные проблемы с PortUnreachableException:-
1. На Солярисе 8, если IPv6 включается тогда порт ICMP, недостижимые пакеты от узлов IPv4, будет казаться, будут отброшены. Это - Солярис 8 ошибок и прослеживается как ошибка 4422658.
2. На некоторых выпусках Microsoft Windows (определенно Windows 98 и Windows NT) порт ICMP недостижимые пакеты неправильно отбрасываются операционной системой, и таким образом PortUnreachableException не бросается. Поскольку на сей раз мы не знаем ни о каких обновлениях Windows Sockets от Microsoft, чтобы устранить эту проблему.
3. На Linux, если пакеты UDP отправляются петлевому адресу и никакому UDP applicatiob к связанному с портом назначения никакой порт ICMP, получается недостижимая индикация, и таким образом никакой PortUnreachableException не бросается. Это - проблема ядра Linux, и мы не знаем о патче в это время.

На многих установках Linux InetAddress.getLocalHost() может возвратить InetAddress, представляющий петлевой адрес (127.0.0.1). Это происходит от многих установок Linux, конфигурирующих/etc/hosts, чтобы отобразить имя узла на петлевой адрес. Если у узла есть статический IP-адрес тогда, файл /etc/hosts должен быть исправлен, чтобы отобразить имя узла на адрес узла.
Если DHCP используется в соединении с динамическим DNS тогда есть две опции (i), изменяют порядок поиска службы имен в /etc/nsswitch.conf, чтобы использовать dns перед файлом hosts (то есть: "узлы: файлы dns"), или (ii) конфигурируют InetAddress, чтобы использовать провайдера службы имен DNS вместо провайдера значения по умолчанию (-Dsun.net.spi.nameservice.provider.1=dns,sun). Эта проблема прослеживается в 4665037.

Свяжитесь с Нами