Я только что обновил сервер до Debian Jessie, который включает Apache 2.4.10 (было 2.2) и PHP 5.6.
Теперь сайты SSL не будут отправлять формы в некоторых случаях в IE11 и iPad Safari (не уверен, что насчет настольного Safari). Firefox и Chrome оба в порядке. В случае сбоя он создает страницу с ошибкой IE "Эта страница не может быть отображена" в IE. Подчеркну: я могу зайти на сайт и увидеть форму, а затем не удается отправить форму.
Это как-то связано с KeepAlive и SSL. Если я отключу KeepAlive в SSL VirtualHost, проблема исчезнет. (Он использует SNI, хотя один из сайтов, показывающих ошибку, является первым SSL). Я использую mpm-itk (и был до обновления).
В IE11 (в Windows 7) это происходит с * SSL (HTTPS) * Apache KeepAlive On, KeepAliveTimeout 5 (по умолчанию) * форм с загрузкой файлов (так что enctype = multipart / form-data), * только когда файл на самом деле предоставлен (это нормально, если нет файла с другими полями или с другими полями; даже 1-байтовый файл вызывает сбой, не зависит от размера файла). * только если загрузка началась в течение 60 секунд после отображения формы (то есть нормально, если вы оставите ее за 60 секунд до нажатия кнопки «Отправить»)
Нет никаких подсказок относительно того, что не удалось. В журналах сервера нет ничего, чтобы показать, что он снова связался с сервером. Ошибка немедленная. В отладчике IE нет ничего, кроме того, что в столбце результатов сетевой страницы написано «(Прервано)» и «Произошла навигация: File: dnserror.htm», что, как я предполагаю, является просто отображаемой страницей, но несмотря на name, насколько я могу судить, ошибки DNS нет. Когда я нажимаю кнопку отправки, Fiddler не показывает сетевой трафик. В средстве просмотра событий Windows нет ничего актуального. Это самое странное - кажется, даже не пытается.
Для Apache 2.4 я настроил SSL, как рекомендовано здесь: https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=apache-2.4.10&openssl=1.0.1k&hsts=no&profile=intermediate . CiperSuite не изменился по сравнению с моей установкой 2.2, но теперь сшивание OCSP включено. Основное изменение версии 2.4 - TLS1.2 (но я считаю, что Фидлер понизил его, так что вряд ли так будет). HSTS включен, но был ранее. SSLLabs дает сайту оценку A + и не указывает на ошибки.
Я пробовал изменить KeepAliveTimeout на 60; а также возвращение в старый BrowserMatch ".MSIE."nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 и BrowserMatch".MSIE."ssl-unclean-shutdown в качестве эксперимента, и я думаю, что это имеет какой-то эффект, а именно то, что он работает после первой попытки. Но первый доступ из недавно запущенного браузера все еще не работает. Возможно, это потому, что он не может определить браузер до тех пор, пока не завершится согласование SSL. К этому времени уже слишком поздно, но после этого в браузере появится дополнительная информация? Также возможно, что я не могу пройти этот процесс менее чем за 60 секунд, поэтому во второй раз все в порядке из-за этого.
Я сделал небольшой тестовый сайт, демонстрирующий проблему: https://iet.davidearl.uk . Он имеет самозаверяющий сертификат только для тестового примера, поэтому при первом посещении появляется предупреждение о сертификате, но это не относится к реальным сайтам, на которых есть проблема. Все, что делает сторона сервера в тестовом примере, - это эхо имени файла отправленного файла, в противном случае исходный HTML-код - это все, что есть.
На iPad проблема кажется еще хуже. Кажется, что вообще невозможно отправлять формы (при этом они отображаются нормально; независимо от того, есть ли у них загрузка файлов). Иногда он просто зависает, иногда имеет внутреннюю страницу с ошибкой («Safari не может открыть страницу, потому что сетевое соединение было потеряно»), в зависимости от того, как построена форма. Опять же, общий фактор - если вы подождете 60 секунд, а затем нажмете кнопку отправки, это сработает. Однако старая версия Safari для ПК (5.1.7) работает нормально.
IE9 в (другой копии) Windows 7 ведет себя как iPad Safari - он просто зависает, если вы не подождете 60 секунд после отображения формы. Microsoft Edge в Windows 10 и IE на планшете Surface RT также, похоже, не работает так же, как IE11. Я также наблюдал один случай, когда PHP "file_get_contents (" https ... ", обращающийся к серверу, постоянно зависал ровно на 60 секунд до успешного завершения, что раньше работало мгновенно.
Я пробовал http: // superuser.com/questions/516030/apache-2-4-on-windows-responds-slowly-hangs-when-serving-some-dynamic-pages - без изменений. Возможно, это связано, но в их дело KeepAlive Off не возымело никакого эффекта; и временное отключение брандмауэра сервера не имеет значения: http: // serverfault.com/questions/678009/windows-8-ie-10-tls-handshake-errors-to-apache-2-2-on-centos-6- 6 Я попытался переупорядочить SSLCipherSuite, чтобы поместить ECDHE-RSA-AES128-SHA256 выше в списке (например, как предлагается здесь: http: // serverfault.com/questions/677338/why-is-internet-explorer-11- cannot-to-connect-to-https-sites-when-tls-1-2-is-ena) Очистить состояние SSL в свойствах Интернета> Содержимое не имеет значения.
Ясно, что существует проблема, связанная с KeepAlive и SSL, которая встречается не часто, но я озадачен тем, что это такое, и нет никаких подсказок, которые помогли бы мне выяснить. Обширный поиск ничего полезного не дал.
Я столкнулся с точно такой же проблемой (потратил довольно много дней на то, чтобы таскать за собой волосы!).
Оказывается, это ошибка в mpm-itk (см. http://lists.err.no/pipermail/mpm-itk/2015-September/thread.html). Эта ошибка исправлена в последней версии, выпущенной вчера.
Вы можете скачать эту новую версию на http://mpm-itk.sesse.net/, но вам придется скомпилировать его самостоятельно из исходников. Это довольно просто, если вы будете следовать инструкциям в файле README.
Спасибо за вопрос! И чтобы cividesk за ответ. Я тоже использую ITK (не уверен, почему больше людей этого не делают - дает полезное разделение привилегий между виртуальными хостами).
Я не хотел перекомпилировать что-то, чтобы избавиться от этой ошибки, предпочитая верить, что однажды она превратится в Джесси и apt-get
волшебным образом исправит это. Но мои клиенты не могут дождаться этого момента!
Я заметил, что в некоторых версиях jQuery это происходило чаще, чем в других, в IE. Так что я решил половину своей проблемы, отказавшись от используемой версии jQuery. Но Safari все еще оставался проблемой - иногда он работал, иногда молча терпел неудачу.
То, как я получил эту работу, было в конфигурации Apache setenvif.conf
файл, который я отредактировал, чтобы включить:
BrowserMatch "Mac OS X" nokeepalive
(кредит в другом месте для этой идеи)
Таким образом, поддержка активности отключена для пользователей Mac. Хотя я не сомневаюсь, что это немного замедляет их работу, это лучше, чем убивать UX / не работать IMO.