2

I have just upgraded a server to Debian Jessie, which includes Apache 2.4.10 (was 2.2), and PHP 5.6.

Now, SSL sites won't submit forms in some circumstances on IE11 and iPad Safari (not sure about desktop Safari). Firefox and Chrome are both OK. When it fails it produces a IE error page "This page can’t be displayed" in IE. Just to stress: I can get to the site and see the form, it's the form submission that then fails.

This is related to KeepAlive and SSL in some way. If I turn KeepAlive off in the SSL VirtualHost, the problem goes away. (It's using SNI, though one of the sites showing the error is the first SSL one). I am using mpm-itk (and was before the upgrade).

In IE11 (on Windows 7), it happens with * SSL (HTTPS) * Apache KeepAlive On, KeepAliveTimeout 5 (the default) * forms with file uploads (so enctype=multipart/form-data), * only when a file is actually supplied (it's OK with no file with or with other fields; even a 1 byte file causes it to fail, not file size dependent). * only if the upload is started within 60 seconds of displaying the form (i.e. it's OK if you leave it 60 seconds before pressing Submit)

There are no clues as to what has failed. There's nothing in the server logs to show it contacted the server again. The error is immediate. There is nothing in the IE debugger other than that it says "(Aborted)" in the result column of the network page and "Navigation occurred: File: dnserror.htm" which I assume is just the page it is displaying, but despite the name there is no dns error as far as I can tell. Fiddler shows no network traffic when I press the submit button. There is nothing relevant in the Windows event viewer. This is the strangest thing about it - it doesn't even seem to try.

For Apache 2.4, I've set up SSL as recommended here: https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=apache-2.4.10&openssl=1.0.1k&hsts=no&profile=intermediate . CiperSuite is unchanged from my 2.2 set up, but OCSP staping is now on. The main 2.4 change is TLS1.2 (but Fidler downgrades this I believe, so it's unlikely to be that). HSTS is turned on, but was previously. SSLLabs gives the site an A+ rating and does not indicate any errors.

I have tried changing KeepAliveTimeout to 60; and also putting back in the old BrowserMatch ".MSIE." nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 and BrowserMatch ".MSIE." ssl-unclean-shutdown as an experiment, and I think this does have some effect, namely that it then works after the first attempt. But the first access from a newly started browser still fails. Possibly this is because it can't determine browser until after the SSL negotiation by which time it is too late, but after that the browser has more information? It's also possible I can't go through this process in under 60 seconds so the second time is OK because of that anyway.

I have made a little test site that demonstrates the problem: https://iet.davidearl.uk . It has a self-signed certificate just for the test case, so there's a certificate warning on first going there, but that's not the case with the real sites that have the problem. All the server side does in the test case is echo the file name of the submitted file, otherwise the HTML source is all there is.

On iPad, the problem seems worse, if anything. It seems not to be able to submit forms at all (while displaying them fine; irrespective of whether they have file uploads). Sometimes it just hangs, sometimes it has an internally generated error page ("Safari cannot open the page because the network connection was lost"), depending how the form is constructed. Again, though, the common factor is if you wait 60 seconds and then press the submit button, it works. An old version of Safari for PC (5.1.7) works OK though.

IE9 on (a different copy of) Windows 7 behaves like iPad Safari - it just hangs unless you wait 60 seconds after displaying the form. Microsoft Edge on Windows 10 and IE on Surface RT tablet also seem to fail in the same way as IE11. I have also observed one case where a PHP "file_get_contents("https..." accessing the server consistently hangs for exactly 60 seconds before suceeding, which worked instantly previously.

I have tried http : // superuser.com/questions/516030/apache-2-4-on-windows-responds-slowly-hangs-when-serving-some-dynamic-pages - no change This perhaps is related, but in their case KeepAlive Off had no effect; and turning off server firewall temporarily makes no difference: http : // serverfault.com/questions/678009/windows-8-ie-10-tls-handshake-errors-to-apache-2-2-on-centos-6-6 I have tried re-ordering the SSLCipherSuite to put ECDHE-RSA-AES128-SHA256 higher up the list (e.g. as suggested here: http : // serverfault.com/questions/677338/why-is-internet-explorer-11-unable-to-connect-to-https-sites-when-tls-1-2-is-ena ) Clear SSL State on Internet Properties > Content makes no difference.

There's clearly a problem related to KeepAlive and SSL, that isn't common, but I'm mystified as to what it is, and there's no clues to help me find out. Extensive searching hasn't yielded anything helpful.

3
  • On a separate test server, having switched off mpm-itk (and related directives, and set permissions for a non mpm-itk) it then works, so I think mpm-itk is probably the root of the problem. Aug 25, 2015 at 17:36
  • Update: it's any further request that fails if done between 5 seconds (the Apache default KeepAliveTimeout) and 60 seconds (MSIE max keep alive interval), not just forms or uploads. Also it affects MacOS/X Safari as well. Aug 28, 2015 at 17:16
  • "I am using mpm-itk..." Thank you for mentioning this; I rarely come across ITK users. You described my problem exactly. Before finding your question here, I was hunting for a race condition in my code that doesn't exist and trying any suggestion I could find with KeepAlive. I haven't tried the patched version yet, but I just tested using my older Ubuntu VM with Apache 2.2-itk and it works fine with IE.
    – jimp
    Oct 23, 2015 at 1:12

2 Answers 2

3

I encountered exactly the same issue (spent quite a few days pulling my hair on this one!).

Turns out it is a bug in mpm-itk (cf. http://lists.err.no/pipermail/mpm-itk/2015-September/thread.html). This bug is now corrected in the latest version released yesterday.

You can download this new version at http://mpm-itk.sesse.net/, but you will have to compile it yourself from source. It is pretty straightforward if you follow the instructions in the README file.

2
  • You have made my day. I searched and tested yesterday and today and still had not considered it could be a bug in Apache 2.4 MPM ITK. I was far off track. Thank you very much.
    – jimp
    Oct 23, 2015 at 1:13
  • I wonder whether/when this will make it into Jessie. Must affect so many sites. Nov 26, 2015 at 14:38
0

Thank you for the Q! And to cividesk for the answer. I, too use ITK (not sure why more people don't - gives v useful separation of privileges between virtualhosts).

I did not want to recompile stuff to get this bug squished, preferring to trust that one day it will make it into Jessie and apt-get will magically fix it. But my clients can't wait until then!

I noticed that certain versions of jQuery caused it to happen more than others, under IE. So I fixed half my problem by dropping back on the jQuery version used. But Safari was still an issue - sometimes it would work sometimes silently fail.

The way I got this working was in the Apache config setenvif.conf file which I edited to include:

BrowserMatch "Mac OS X" nokeepalive

(credit due elsewhere for this idea)

This way keepalive is turned off for Mac users. While I don't doubt that this slows things down for them a bit, it's better than killing the UX/not working IMO.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .