Internet Explorer, 512-byte error page fix doesn't work. Neglects gzip compression.

[charris]

Internet Explorer won't display a custom error page (e.g., the one generated by WordPress after a comment form validation fails) if the resulting page is less than 512 bytes; in this scenario, IE will display its own proprietary error message instead. This can prevent the user from seeing important WordPress error messages (such as form validation errors after submitting a comment). (See ​http://perishablepress.com/press/2008/01/21/important-note-for-your-custom-error-pages/ for more info on this IE bug).

A WordPress developer attempted to fix this problem. In wp-includes/functions.php, line 2293, the str-repeat() function is used in an attempt to pad the error page with enough characters such that the resulting HTTP response will be greater than 512 bytes, therefore avoiding the aforementioned Internet Explorer problem.

The problem is that the WordPress developer neglected to account for gzip compression being used in sending the HTTP response message to the browser. In other words, the error page may have 512 characters, but after being compressed, is smaller than 512 bytes.

Proposed resolution is to always pad the error page with enough characters such that it is greater than 512 bytes, even after gzip compression.

[DD32]

Oh you're freaking kidding me, IE uses the pre-degzip'd length?!

So it looks like that means a unique phrase is needed, Or extra HTML Markup..

[charris]

Yep, IE seems to only look at the "Content-Length" header of the HTTP message, specifically. If it's any help, I've written up a blog post describing the problem, including the raw HTTP messages/headers showing the size and a less-than-elegant temporary fix that might be helpful to folks in the meantime: ​http://www.clintharris.net/2009/ie-512-byte-error-pages-and-wordpress/

[Viper007Bond]

Then there's the whole problem of the different amount of gzip compressions. Padding to bigger than 512 when on default may be fine, but what about the slower/better compression settings?

Fun times (and stop using IE! :P).

[Denis-de-Bernardy]

quick question: what would happen if WP reports an erroneous content length?

[DD32]

quick question: what would happen if WP reports an erroneous content length?

Then some browsers will choke, Some will never finish loading the page, and some will just end up being quirky. (I suspect some HTTP servers/proxies would also choke or something)

[Denis-de-Bernardy]

k... and there is no means to disable gzip compression, right? :-|

if not, this should get punted to Future, as there is no patch in sight beyond adding hidden HTML.

[Denis-de-Bernardy]

hidden HTML could be a huge HTML comment, btw. for instance, an angry rant against IE. :D

[hakre]

Please provides Steps to reproduce. For Example to take a closer look into this Issue it might be necessary to check which HTTP Status Codes actually are reported back from WP when displaying such messages.

[Denis-de-Bernardy]

you might manage to reproduce by playing around with the wp-comments-post.php file. have it spit a wp_die() when browsed, instead of a plain text header with no content.

[hakre]

Unable to reproduce:
I could not reproduce the problem with Internet Explorer 6 on Windows XP SP3. Friendly Error Messages (Kurze Fehlermeldungen in German) were double-checked. Teste with on and off, tested with non-compressd and compressed output (both under 512 bytes in total) not running into any problems (displaying the the IE-Message instead the wp_die(); message.

The Defect should be for IE 5.x and IE 6.x according to the documentation of the manufacturer (Microsoft). The IE Version I did a test with was: 6.0.2900.5512.xpsp_sp3_qfe.09206-1316.

Anyway, I made a patch. This enlarges the page size to about 2k but it is after the body tag sothat display should work hopefully as fast as ususal.

[hakre]

Patch for unconfirmed behaviour but propper worken as intended with compression.

[hakre]

I would like to have an actual report by someone that he/she encountered the so called friendly error message by internet explorer.

here is how I tested:

fake.html in webroot of blog:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Insert title here</title>
</head>
<body>
<form method="post" action="wp-comments-post.php">
<input name="comment_post_ID" value="1" />
<input type="submit" />
</form>
</form>
</body>
</html>

this provocates a wp_die() for the default first post.

[hakre]

File for testing

[Denis-de-Bernardy]

Added a comment in Clint's post. hopefully a helpful tester who knows how to reproduce it (Clint seems to describe a way) will show up and give the patch a try.

[hakre]

Well according to the Developer Docs on Microsoft.com (MSDN), Internetexplorer does behave that way. But maybe I just was not able to reproduce because this misbehavior of IE ist patched out since SP2 or SP3 of the Windows Operating System.

[charris]

Replying to Denis-de-Bernardy:

Added a comment in Clint's post. hopefully a helpful tester who knows how to reproduce it (Clint seems to describe a way) will show up and give the patch a try.

I (the original reporter) have tested the patch with WP 2.7--seems to work fine. Thanks Denis and hakre!

[hakre]

Well, was nice to learn about that. I know that IE is really dumb, but even after years of webdevelopment you still learn how far that was going. It is so important that Windows no longer ships with that by Default IMHO.

[azaozz]

(In [11340]) Fix IE 512-byte minimum page length bug, props hakre, fixes #8942

[miqrogroove]

This patch fails when certain chunk sizes are emitted after Transfer-Encoding: chunked. Random string output must be moved before any inline function calls to prevent chunking.

See #11289

[hakre]

Replying to miqrogroove:

This patch fails when certain chunk sizes are emitted after Transfer-Encoding: chunked. Random string output must be moved before any inline function calls to prevent chunking.

See #11289

Then we still have an issue here?

[miqrogroove]

No, I fixed the IE bug in #11289. The remaining problems are in #11286.

[GaryJ]

Is the 512 bytes padding fix still needed for the currently supported set of browsers?

[azaozz]

Replying to GaryJ:

Don't think so, this bug is supposed to be only in IE < 7.

[miqrogroove]

Replying to azaozz:

this bug is supposed to be only in IE < 7.

That is not correct.