Acabo de actualizar un servidor a Debian Jessie, que incluye Apache 2.4.10 (antes 2.2) y PHP 5.6.
Ahora, los sitios SSL no enviarán formularios en algunas circunstancias en IE11 y iPad Safari (no estoy seguro acerca de Safari de escritorio). Tanto Firefox como Chrome están bien. Cuando falla, genera una página de error de IE "Esta página no se puede mostrar" en IE. Solo para enfatizar: puedo acceder al sitio y ver el formulario, lo que luego falla es el envío del formulario.
Esto está relacionado de alguna manera con KeepAlive y SSL. Si desactivo KeepAlive en SSL VirtualHost, el problema desaparece. (Está usando SNI, aunque uno de los sitios que muestra el error es el primero SSL). Estoy usando mpm-itk (y lo estaba antes de la actualización).
En IE11 (en Windows 7), sucede con * SSL (HTTPS) * Apache KeepAlive On, KeepAliveTimeout 5 (el valor predeterminado) * formularios con carga de archivos (por lo que enctype=multipart/form-data), * solo cuando un archivo está realmente suministrado (está bien sin ningún archivo con o con otros campos; incluso un archivo de 1 byte hace que falle, no depende del tamaño del archivo). * solo si la carga se inicia dentro de los 60 segundos de mostrar el formulario (es decir, está bien si lo deja 60 segundos antes de presionar Enviar)
No hay pistas sobre lo que ha fallado. No hay nada en los registros del servidor que demuestre que se contactó con el servidor nuevamente. El error es inmediato. No hay nada en el depurador de IE aparte de que dice "(Abortado)" en la columna de resultados de la página de red y "Se produjo navegación: Archivo: dnserror.htm", que supongo que es solo la página que se muestra, pero a pesar de nombre, hasta donde yo sé, no hay ningún error de DNS. Fiddler no muestra tráfico de red cuando presiono el botón enviar. No hay nada relevante en el visor de eventos de Windows. Esto es lo más extraño: ni siquiera parece intentarlo.
Para Apache 2.4, configuré SSL como se recomienda aquí:https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=apache-2.4.10&openssl=1.0.1k&hsts=no&profile=intermediate. CiperSuite no ha cambiado desde mi configuración 2.2, pero el staping OCSP ahora está activado. El principal cambio de 2.4 es TLS1.2 (pero creo que Fidler lo rebaja, por lo que es poco probable que sea así). HSTS está activado, pero lo estaba anteriormente. SSLLabs le otorga al sitio una calificación A+ y no indica ningún error.
Intenté cambiar KeepAliveTimeout a 60; y también volver a colocar el antiguo BrowserMatch ".MSIE."nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 y BrowserMatch".MSIE." ssl-unclean-shutdown como experimento, y creo que esto tiene algún efecto, es decir, que funciona después del primer intento. Pero el primer acceso desde un navegador recién iniciado aún falla. Posiblemente esto se deba a que no puede determinar navegador hasta después de la negociación SSL, momento en el que ya es demasiado tarde, pero después de eso el navegador tiene más información. También es posible que no pueda realizar este proceso en menos de 60 segundos, por lo que la segunda vez está bien por eso de todos modos.
He creado un pequeño sitio de prueba que demuestra el problema:https://iet.davidearl.uk. Tiene un certificado autofirmado solo para el caso de prueba, por lo que hay una advertencia de certificado al acceder allí por primera vez, pero ese no es el caso con los sitios reales que tienen el problema. Todo lo que hace el lado del servidor en el caso de prueba es repetir el nombre del archivo enviado; de lo contrario, la fuente HTML es todo lo que hay.
En iPad, el problema parece peor, en todo caso. Parece que no puede enviar ningún formulario (aunque los muestra bien; independientemente de si tienen archivos cargados). A veces simplemente se cuelga, a veces tiene una página de error generada internamente ("Safari no puede abrir la página porque se perdió la conexión de red"), dependiendo de cómo esté construido el formulario. Sin embargo, una vez más, el factor común es que si espera 60 segundos y luego presiona el botón de enviar, funciona. Sin embargo, una versión antigua de Safari para PC (5.1.7) funciona bien.
IE9 en (una copia diferente de) Windows 7 se comporta como iPad Safari: simplemente se bloquea a menos que espere 60 segundos después de mostrar el formulario. Microsoft Edge en Windows 10 e IE en la tableta Surface RT también parecen fallar de la misma manera que IE11. También he observado un caso en el que un PHP "file_get_contents("https..." que accede al servidor se bloquea constantemente durante exactamente 60 segundos antes de tener éxito, lo que funcionó instantáneamente anteriormente.
He probado http: // superuser.com/questions/516030/apache-2-4-on-windows-responds-slowly-hangs-when-serving-some-dynamic-pages - sin cambios Esto quizás esté relacionado, pero en su caso KeepAlive Off no tuvo efecto; y desactivar temporalmente el firewall del servidor no hace ninguna diferencia: http: // serverfault.com/questions/678009/windows-8-ie-10-tls-handshake-errors-to-apache-2-2-on-centos-6- 6 He intentado reordenar SSLCipherSuite para colocar ECDHE-RSA-AES128-SHA256 más arriba en la lista (por ejemplo, como se sugiere aquí: http://serverfault.com/questions/677338/why-is-internet-explorer-11- incapaz de conectarse a sitios https cuando tls-1-2-is-ena) Borrar el estado SSL en Propiedades de Internet> El contenido no hace ninguna diferencia.
Claramente hay un problema relacionado con KeepAlive y SSL, que no es común, pero no sé qué es y no hay pistas que me ayuden a descubrirlo. Una búsqueda exhaustiva no ha arrojado nada útil.
Respuesta1
Encontré exactamente el mismo problema (¡pasé bastantes días tirándome de los pelos con este!).
Resulta que es un error en mpm-itk (cf.http://lists.err.no/pipermail/mpm-itk/2015-September/thread.html). Este error ahora se corrigió en la última versión lanzada ayer.
Puedes descargar esta nueva versión enhttp://mpm-itk.sesse.net/, pero tendrás que compilarlo tú mismo desde el código fuente. Es bastante sencillo si sigues las instrucciones del archivo README.
Respuesta2
¡Gracias por la pregunta! Y paracivideskpor la respuesta. Yo también uso ITK (no estoy seguro de por qué más personas no lo hacen; proporciona una separación muy útil de privilegios entre hosts virtuales).
No quería volver a compilar cosas para solucionar este error, prefiero confiar en que algún día llegará a Jessie y apt-getlo solucionará mágicamente. ¡Pero mis clientes no pueden esperar hasta entonces!
Noté que ciertas versiones de jQuery causaron que esto sucediera más que otras, en IE. Así que solucioné la mitad de mi problema volviendo a la versión de jQuery utilizada. Pero Safari seguía siendo un problema: a veces funcionaba y otras fallaba silenciosamente.
La forma en que hice que esto funcionara fue en el setenvif.confarchivo de configuración de Apache que edité para incluir:
BrowserMatch "Mac OS X" nokeepalive
(crédito adeudado en otra parte por esta idea)
De esta manera, keepalive está desactivado para los usuarios de Mac. Si bien no dudo que esto les ralentice un poco las cosas, es mejor que matar la UX/no funcionar en mi opinión.