WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

Last modified 2 years ago

#8942 closed defect (bug) (fixed)

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

Reported by: charris Owned by:
Milestone: 2.8 Priority: normal
Severity: normal Version: 2.7
Component: Optimization Keywords: dev-feedback
Focuses: Cc:

Description

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.

Attachments (2)

8942.patch (998 bytes) - added by hakre 5 years ago.
Patch for unconfirmed behaviour but propper worken as intended with compression.
8942-test.html (395 bytes) - added by hakre 5 years ago.
File for testing

Download all attachments as: .zip

Change History (26)

comment:1 DD325 years ago

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..

comment:2 charris5 years ago

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/

comment:3 Viper007Bond5 years ago

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).

comment:4 Denis-de-Bernardy5 years ago

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

comment:5 DD325 years ago

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)

comment:6 Denis-de-Bernardy5 years ago

  • Keywords needs-patch added

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.

comment:7 Denis-de-Bernardy5 years ago

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

comment:8 hakre5 years ago

  • Keywords reporter-feedback added

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.

comment:9 Denis-de-Bernardy5 years ago

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.

comment:10 hakre5 years ago

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.

hakre5 years ago

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

comment:11 hakre5 years ago

  • Keywords has-patch added; needs-patch removed

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.

hakre5 years ago

File for testing

comment:12 follow-up: Denis-de-Bernardy5 years ago

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.

comment:13 hakre5 years ago

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.

comment:14 in reply to: ↑ 12 charris5 years ago

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!

comment:15 hakre5 years ago

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.

comment:16 Denis-de-Bernardy5 years ago

  • Keywords tested commit added; reporter-feedback removed

comment:17 Denis-de-Bernardy5 years ago

  • Component changed from General to Optimization

comment:18 azaozz5 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:19 follow-up: miqrogroove4 years ago

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

comment:20 in reply to: ↑ 19 hakre4 years ago

  • Keywords dev-feedback added; has-patch tested commit removed

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?

comment:21 miqrogroove4 years ago

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

comment:22 follow-up: GaryJ2 years ago

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

comment:23 in reply to: ↑ 22 ; follow-up: azaozz2 years ago

Replying to GaryJ:

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

comment:24 in reply to: ↑ 23 miqrogroove2 years ago

Replying to azaozz:

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

That is not correct.

Note: See TracTickets for help on using tickets.