Я только что обновил сервер до 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 нет ничего, кроме того, что он говорит "(Aborted)" в столбце результатов сетевой страницы и "Navigation performed: File: dnserror.htm", что, как я предполагаю, является просто страницей, которую он отображает, но, несмотря на название, насколько я могу судить, ошибки 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 (но Fidler понижает его, я полагаю, так что вряд ли это так). HSTS включен, но был включен ранее. SSLLabs дает сайту рейтинг A+ и не указывает на какие-либо ошибки.
Я попробовал изменить KeepAliveTimeout на 60; а также вернуть старый BrowserMatch ".МСИЭ." nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 и BrowserMatch ".МСИЭ."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-unable-to-connect-to-https-sites-when-tls-1-2-is-ena ). Очистка состояния SSL в свойствах Интернета > Содержимое не дает результата.
Очевидно, что проблема связана с KeepAlive и SSL, что не является распространенной, но я не могу понять, что это такое, и нет никаких зацепок, которые помогли бы мне это выяснить. Обширные поиски не дали ничего полезного.
решение1
Я столкнулся с точно такой же проблемой (провел несколько дней, ломая над ней голову!).
Оказывается, это ошибка в mpm-itk (см.http://lists.err.no/pipermail/mpm-itk/2015-September/thread.html). Эта ошибка исправлена в последней версии, выпущенной вчера.
Вы можете загрузить эту новую версию по адресуhttp://mpm-itk.sesse.net/, но вам придется скомпилировать его самостоятельно из исходников. Это довольно просто, если следовать инструкциям в файле README.
решение2
Спасибо за вопрос! И заcivideskдля ответа. Я тоже использую ITK (не знаю, почему большинство людей этого не делают - дает очень полезное разделение привилегий между виртуальными хостами).
Я не хотел перекомпилировать что-то, чтобы исправить этот баг, предпочитая верить, что однажды он попадет в Джесси и apt-getчудесным образом исправит его. Но мои клиенты не могут дождаться этого момента!
Я заметил, что некоторые версии jQuery вызывали это чаще, чем другие, в IE. Поэтому я исправил половину проблемы, вернув используемую версию jQuery. Но Safari все еще был проблемой — иногда он работал, иногда молча зависал.
Я добился этого с помощью setenvif.confфайла конфигурации Apache, который я отредактировал, включив в него следующее:
BrowserMatch "Mac OS X" nokeepalive
(за эту идею нужно отдать должное кому-то другому)
Таким образом, keepalive отключается для пользователей Mac. Хотя я не сомневаюсь, что это немного замедляет работу, это лучше, чем убивать UX/не работать, ИМХО.