Ticket #8942 (closed defect (bug): fixed)

Opened 3 years ago

Last modified 21 months ago

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

Reported by: charris Owned by: anonymous
Priority: normal Milestone: 2.8
Component: Optimization Version: 2.7
Severity: normal Keywords: dev-feedback
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

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

Change History

comment:1   DD32 — 3 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   charris — 3 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   Viper007Bond — 3 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-Bernardy — 3 years ago

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

comment:5   DD32 — 3 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-Bernardy — 3 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-Bernardy — 3 years ago

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

comment:8   hakre — 3 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-Bernardy — 3 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   hakre — 3 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.

hakre — 3 years ago

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

comment:11   hakre — 3 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.

hakre — 3 years ago

File for testing

comment:12 follow-up: ↓ 14   Denis-de-Bernardy — 3 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   hakre — 3 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   charris — 3 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   hakre — 3 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-Bernardy — 3 years ago

  • Keywords tested commit added; reporter-feedback removed

comment:17   Denis-de-Bernardy — 3 years ago

  • Component changed from General to Optimization

comment:18   azaozz — 3 years ago

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

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

comment:19 follow-up: ↓ 20   miqrogroove — 2 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   hakre — 21 months 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   miqrogroove — 21 months ago

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

Note: See TracTickets for help on using tickets.