<-
Apache > HTTP Server > Documentation > Version 2.0 > Miscellaneous Documentation

Известные Проблемы в Клиентах

предупреждение:

этот документ не был полностью обновлен, чтобы принять во внимание изменения, сделанные в 2.0 версиях Apacheского Сервера HTTP. Часть информации может все еще быть уместной, но пожалуйста используйте это с заботой.

в течение долгого времени Apache Группа обнаружила или уведомлена относительно проблем с различными клиентами, которых мы должны были работать вокруг, или объяснять. Этот документ описывает эти проблемы и доступные работы. Это не устроено ни в каком специфическом заказе. Немного дружественных отношений со стандартами приняты, но не необходимые.

для краткости, навигатор обратится к продукту Навигатора Netscape (который в более поздних версиях был переименованный "Коммуникатор" и различный другие названия), и MSIE обратится к продукту Internet Explorer Microsoft. Все торговые марки и авторские права принадлежат их соответствующим компаниям. Мы приветствуем вход от различных авторов клиента, чтобы исправить несогласованности в этой бумаге, или предоставить нам точные числа версии, где вещи нарушены/установлены.

для ссылки, RFC1945 определяет HTTP/1.0, и RFC2068 определяет HTTP/1.1. Апач на версию 1.2 - сервер HTTP/1.1 (с дополнительным полномочием HTTP/1.0).

различный из этих работ вызваны переменными окружающей среды. admin типично управляет, которые установлены, и для который клиенты, при использовании mod_browser . если иначе не отмечено все эти работы существуют в версиях 1.2 и позже.

top

Trailing CRLF on POSTs

это - проблема наследства. CERN webserver требуемый POST данные, чтобы иметь дополнительное CRLF следующий за этим. Таким образом много клиентов посылают дополнительное CRLF это не включено в Content-Length из запроса. Апачские работы вокруг этой проблемы, едящий любые пустые линии, которые появляются перед запросом.

top

Broken KeepAlive

различные клиенты имели сломанное выполнение keepalive (постоянные связи). В особенности версии Windows Навигатора 2.0 очень перепутаны когда времена сервера праздная связь. Работа присутствует на неплатеже config файлы:

BrowserMatch Mozilla/2 nokeepalive

отметить, что это соответствует некоторым более ранним версиям MSIE, который начал практику запроса Mozilla в их вереницах пользовательского агента точно так же как Навигатор.

MSIE 4.0b2, который утверждает, что поддержал HTTP/1.1, должным образом не поддерживает keepalive, когда это используется на 301, или 302 (переадресовывают) ответы. К сожалению Апач nokeepalive кодекс до 1.2.2 не работал бы с клиентами HTTP/1.1. Вы должны примениться this patch к версии 1.2.1. Тогда добавьте это к вашему config:

BrowserMatch "MSIE 4\.0b2;" nokeepalive

top

Incorrect interpretation of HTTP/1.1 in response

указывать от секции 3.1 RFC1945:

HTTP использует "<MAJOR>.<MINOR>" нумеруя схему указывать версии протокола. Протокол versioning политика предназначен, чтобы позволить отправителю указывать формат сообщения и его вместимости для того, чтобы понять далее коммуникацию HTTP, а не особенности, полученные через ту коммуникацию.

так как Apache - сервер HTTP/1.1, это указывает чтобы часть его ответа. Много авторов клиента по ошибке рассматривают эту часть ответа как признак протокола, что ответ находится в, и затем отказываться принять ответ.

первый главный признак этой проблемы был с серверами AOL по доверенности. Когда Apache 1.2 вошел в бету, это был первый широко распространенный сервер HTTP/1.1. После некоторого обсуждения, AOL установил их полномочия. В ожидании подобных проблем, force-response-1.0 переменная окружающей среды была добавлена к Apacheу. Когда существующий Apache укажет "HTTP/1.0" в ответ на клиента HTTP/1.0, но не будет в любом другом изменении пути ответ.

пред1.1 Явских Комплекта Развития (JDK), который используется во многих клиентах (включая Навигатора 3.x и MSIE 3.x) показывают эту проблему. Также, как и некоторые из ранних предварительных показов 1.1 JDK. Мы думаем, что это установлено в 1.1 выпусках JDK. В любом случае работа:

BrowserMatch Java/1.0 force-response-1.0
BrowserMatch JDK/1.0 force-response-1.0

RealPlayer 4.0 от Прогрессивных Сетей также показывает эту проблему. Однако они установили это в версии 4.01 игрока, но версия 4.01 использует то же самое User-Agent как версия 4.0. Работа - все еще:

BrowserMatch "RealPlayer 4.0" force-response-1.0

top

Requests use HTTP/1.1 but responses must be in HTTP/1.0

MSIE 4.0b2 имеет эту проблему. Его Ява VM делает запросы в формате HTTP/1.1, но ответах, должна быть в формате HTTP/1.0 (в частности это не понимает chunked ответы). Работа к глупому Apacheу в веру запросу, вошел в формат HTTP/1.0.

BrowserMatch "MSIE 4\.0b2;" downgrade-1.0 force-response-1.0

эта работа доступна в 1.2.2, и в a patch против 1.2.1.

top

Boundary problems with header parsing

все версии Навигатора от 2.0 до 4.0b2 (и возможно позже) имеют проблему, если перемещение CRLF удара головой ответа начинается в погашении 256, 257 или 258 из ответа. BrowserMatch для этого соответствовал бы на почти каждом хите, таким образом работа позволяется автоматически на всех ответах. Осуществленная работа обнаруживает, когда это условие произошло бы в ответе и добавляет дополнительное дополнение к удару головой, чтобы выдвинуть перемещение CRLF прошлое погашение 258 из ответа.

top

Multipart responses and Quoted Boundary Strings

на многослойных ответах некоторые клиенты не будут принимать кавычки (") вокруг граничной вереницы. Стандарт ПАНТОМИМЫ рекомендует, чтобы такие кавычки использовались. Но клиенты были вероятно написаны основанный на одном из примеров в RFC2068, который не включает кавычки. Апач не включает кавычки на его граничных вереницах к работе эта проблема.

top

Byterange Requests

запрос byterange используется, когда клиент желает восстановить часть объекта, не обязательно весь объект. Был очень старый проект, который включал эти byteranges в URL. Старые клиенты, типа Навигатора 2.0b1 и MSIE 3.0 для МАКИНТОША показывают это поведение, и это появится в регистрациях доступа серверов как (подведенные) попытки восстановить URL с перемещением "; xxx-yyy". Апач не пытается осуществить это вообще.

последующий проект этого стандарта определяет удар головой Request-Range , и тип ответа multipart/x-byteranges . стандарт HTTP/1.1 включает этот проект с немногими, устанавливает, и это определяет удар головой Range и тип multipart/byteranges .

навигатор (версии 2 и 3) посылает оба Range и Request-Range удары головой (с той же самой ценностью), но не принимает a multipart/byteranges ответ. Ответ должен быть multipart/x-byteranges . как работа, если Apache получает a Request-Range удар головой это считает это "более высоким приоритетом" чем a Range удар головой и в использованиях ответа multipart/x-byteranges .

вставной Читатель Adobe Acrobat делает обширное использование byteranges, и до версии 3.01 поддерживает только multipart/x-byterange ответ. К сожалению нет никакого ключа, что это - вставное создание запроса. Если вставное используется с Навигатором, вышеупомянутые прекрасные работы работы. Но если вставное будет использоваться с MSIE 3 (на Windows), то работа не будет работать, потому что MSIE 3 не дает Range-Request ключ, который Навигатор делает. К работе это, Apacheские специальные случаи "MSIE 3" в User-Agent и подачи multipart/x-byteranges . отметить, что потребность этого с MSIE 3 происходит фактически из-за вставного Акробата, не из-за браузера.

Netscape Communicator, кажется, не выпускает нестандартное Request-Range удар головой. Когда Акробат, вставной до версии 3.01 используется с этим, это не будет должным образом понимать byteranges. Пользователь должен модернизировать их читателя Акробата к 3.01.

top

Set-Cookie header is unmergeable

спецификации HTTP говорят, что юридическое слить удары головой с двойными названиями в один (отделенный запятыми). Некоторые браузеры, которые поддерживают Печенье, не любят слитые удары головой и предпочитают что каждый Set-Cookie удар головой посылают отдельно. Разбирая удары головой, возвращенные CGI, Apache явно избежит сливать любого Set-Cookie удары головой.

top

Expires headers and GIF89A animations

версии навигатора 2 - 4 будут ошибочно повторно просить мультипликации GIF89A на каждой петле мультипликации, если первый ответ включал Expires удар головой. Это случается независимо от того, как далеко в будущем время истечения установлено. Нет никакой работы, снабженной Apache, однако есть, рубит для 1.2 и для 1.3 .

top

POST without Content-Length

в определенном Навигаторе ситуаций 3.01 до 3.03, кажется, неправильно выпускают ПОСТ без тела запроса. Нет никакой известной работы. Это было установлено в Навигаторе 3.04, Netscape обеспечивает некоторых information . есть также some information о фактической проблеме.

top

JDK 1.2 betas lose parts of responses.

http клиент в JDK1.2beta2 и beta3 выбросит первую часть тела ответа, когда и удары головой и первая часть тела посылаются в том же самом пакете сети И держат-alive's, используются. Если любое условие не встречено тогда, это работает прекрасное.

см. также УДОСТОВЕРЕНИЕ ЛИЧНОСТИ ОШИБКИ 4124329 И 4125538 при явской связи разработчика.

если Вы видите эту ошибку самостоятельно, Вы можете добавить следующую директиву BrowserMatch, чтобы работать вокруг этого:

BrowserMatch "Java1\.2beta[23]" nokeepalive

мы не защищаем это, хотя начиная с наклона назад для беты программное обеспечение - обычно не хорошая идея; идеально это получает установленные, новые беты, или заключительный выпуск выходит, и никто не использует сломанное старое программное обеспечение больше. В теории.

top

Content-Type change is not noticed after reload

навигатор (все версии?) припрячет про запас content-type для объекта "навсегда". Используя перезаряжают, или shift-reload не будет заставлять Навигатора замечать a content-type изменение. Единственная работа - для пользователя, чтобы смыть их тайники (память и диск). Посредством примера, некоторые люди могут использовать старое mime.types файл, который не наносит на карту .htm к text/html , в этом случае Apache будет неплатеж к посылке text/plain . если пользователь просит страницу, и этим служат text/plain . после того, как admin устанавливает сервер, пользователь должен будет смыть их тайники прежде, чем объект будут показывать с правильным text/html напечатать.

top

MSIE Cookie problem with expiry date in the year 2000

версии 3.00 и 3.02 MSIE (без относящегося к двухтысячному году участка) не обращаются с датами окончания срока действия печенья в году 2000 должным образом. Годы после 2000 и до 2000 работают прекрасные. Это установлено в служебном пакете IE4.01 1, и в относящемся к двухтысячному году участке для IE3.02. Пользователи должны избежать использовать даты окончания срока действия в году 2000.

top

Lynx incorrectly asking for transparent content negotiation

версии 2.7 и 2.8 браузера Рыси посылают, "ведите переговоры: сделка" удар головой в их запросах, который является признаком браузер, поддерживает прозрачные довольные переговоры (TCN). Однако браузер не поддерживает TCN. На версию 1.3.4, Apache поддерживает TCN, и это вызывает проблемы с этими версиями Рыси. Поскольку версии будущего работы Apacheа будут игнорировать этот удар головой когда послано клиентом Рыси.

top

MSIE 4.0 mishandles Vary response header

MSIE 4.0 не обращается с Измененным ударом головой должным образом. Измененный удар головой произведен mod_rewrite в Apacheе 1.3. Результат - ошибка от MSIE высказывание, это не может загрузить требуемый файл. Есть больше деталей в PR#4118 .

работа должна добавить следующий к файлам конфигурации вашего сервера:

BrowserMatch "MSIE 4\.0" force-no-vary

(эта работа только доступна с выпусками после 1.3.6 из Apacheского Web-сервера.)