Other Software

ID #260

My POST to a secure form results in a blank page, the same form, or a 500 Internal Server Error.

Applies to: Grid System

This might happen to you if you are using the Microsoft Internet Explorer browser version 6.x that has a buggy Service Pack applied to it through Windows Update. The buggy patch to IE causes the browser to intermittently send no POST data when posting to a form that is encrypted with SSL.

You can tell if your Internet Explorer browser has the bad update on it by clicking Help, About Internet Explorer from the top menu:

and then looking for patch number Q832894 in the patch list:

If you find that patch, which is the one that causes Internet Explorer to be broken when communicating with secure forms, then you need to get the next patch mentioned in this Microsoft Knowledge Base article that patches the broken patch. The article identifier is KB831167 if you need to search for it in the Microsoft archives.

The solution to the problem is to download the patch file named Q831167.exe, save it to your Desktop, then doubleclick the file to run it. Running the file will install the patch and prompt you to restart your computer. After you reboot your computer, you should see that patch in the list of patches when you look at About Internet Explorer:

The knowledge base article at Microsoft also offers editting your registry as an alternative to downloading the patch. You should never edit your registry unless you know what you are doing, and editting the registry is not necessary if you have downloaded and installed the above Q831167 patch.

At the time of this writing, February 26, 2004, patch Q832894 (the bad one) is applied automatically through the Windows Update. However, patch Q831167 (the good one) that fixes the intermittent empty post problem, is not available through Windows Update and must be searched for manually by Internet Explorer users.

No other browsers (Mozilla, Netscape, Firefox, Galleon, etc) experience this empty POST problem. It only occurs with Internet Explorer 6 browsers that have Q832894 without Q831167.

The problem has nothing do do with Apache, PHP, or any cgi script and cannot be fixed with any script programming. This problem can only be fixed by the site visitor fixing their browser.

Last update: 2010-10-03 16:59
Author: FAQ Admin
Revision: 1.2

Digg it! Share on Facebook Print this record Send FAQ to a friend Show this as PDF file
Please rate this FAQ:

Average rating: 2 (7 Votes)

completely useless 1 2 3 4 5 most valuable

You can comment this FAQ

Comment of Anonymous:
My SSL bank site kept either timing out or telling me I had clicked the back button on my browser, i am using AOL browser, patch 831167 sorted it.
Added at: 2004-03-04 01:45

Comment of Anonymous:
From a post at http://www.mail-archive.com/discuss-list@opensrs.org/msg24118.html
a reported server-side fix is to put this line in a file named .htaccess that is located in the same directory as, or above the directory where you are serving pages:

SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0

That statement would go all on 1 line, even though it may appear to wrap on multiple lines in this note.

Added at: 2004-03-11 17:08

Comment of Anonymous:
Microsoft have just released this months patches on Windows Update, but have not released Q831167 yet, so machines that patch only from Windows Update will still be flawed.
Added at: 2004-03-12 08:38

Comment of Anonymous:
"Empty Content-Length on POST from Internet Explorer"
Added at: 2004-03-28 14:33

Comment of Anonymous:
The .htaccess fix didn't work for us. We're on SunOS at your-site.com. As far as I know, we're not on a secure site, either. I'm just posting plain-old HTML form data to a PHP page. I have it stripped down to bare essentials, and still get the problem about 50% of the time. Removing the offending MS Security patch does fix the problem, as does applying the patch-fix patch. It's incredibly galling that MS has not called this a critical problem and pushed the patch out to users.
Added at: 2004-03-21 09:17

Comment of Anonymous:
This bug is still present in the newest build of Internet Explorer (With Service Pack 2, as of the date of writing). This time the bug appears when the submitting form contains a file upload.
A normal post without encoded data doesn't result in the display of an empty page.
The problem can be fixed by applying the NoKeepAlive setting to Apache for SSL connections.
Added at: 2004-12-06 04:23

Comment of Anonymous:
And As of 5-9-06, with the most recent IE updates, it\'s still broken... Go IE!!

My specific issue was that uploading files behind ssl in Internet Explorer would first display a blank page, upload the file, then return my response \"thank you\" page. I think the orginal problem was that IE would post to the server -- My hunch is that the \"quick fix\" for the developers of IE was to simply send the post again after the \"broken\" post. So you get the non-post headers, a blank page is returned, then the browser reposts to correct the problem. Needless to say, users think the upload broke as soon as they hit the blank page. Thanks a lot, Microsoft!

This fixed it:
In apache\'s httpd.conf file, find:

# The following directives modify normal HTTP response behavior to
# handle known problems with browser implementations.
BrowserMatch \"Mozilla/2\" nokeepalive
BrowserMatch \"MSIE 4\\.0b2;\" nokeepalive downgrade-1.0 force-response-1.0
BrowserMatch \"RealPlayer 4\\.0\" force-response-1.0
BrowserMatch \"Java/1\\.0\" force-response-1.0
BrowserMatch \"JDK/1\\.0\" force-response-1.0

(occurs around line 950 or so in my file)
Add the line:

SetEnvIf User-Agent \".*MSIE.*\" nokeepalive ssl-unclean-shutdown

You must have mod_setenvif enabled in apache for this to work.
Added at: 2006-05-09 11:19

Comment of Anonymous:
We are having this same problem.

The caveat with setting the keepalive off is that all web pages generate huge connection counts and impact on web server performance.

There must be a better way around this.

I can't believe that MS has been ignoring this for 4 years now...

Added at: 2006-11-14 21:16

Comment of Anonymous:
This problem can also appear if you are using IIS with client certificates. See this article for how to resolve this:

Added at: 2007-04-30 04:35

Comment of Anonymous:
I know this is an old article, but a related bug pops up in IE7. If you are experiencing empty POST variables with just IE 7, try the nokeepalive thing.
More info on http://qfox.nl/index.php?a=1&l=186&t=1

Thanks :)
Added at: 2008-06-03 14:27

Comment of Anonymous:
Sorry, the article moved to http://qfox.nl/notes?1
Added at: 2009-01-13 03:06

Comment of Dmitri:
I think one possible solution to this problem is to preface AJAX POST in your application with some dummy GET request to the server, so that it would ping an underlying TCP connection. Doing this combined with large keep-alive timeout on server/client, large enough to span a possible time interval between GET and its following POST on even heavy loaded server, I believe, will practically reduce the risk of this error.
Added at: 2011-07-03 06:46