Please... let be sure that those injected characters are going to be replied only to a browser request, possibly only IE. Technically as long as the gzipped body stays over 512 byte IE will show the page. Lets not forget, pleeeease, that the thread started requesting to delete those nasty 512 bytes (and I'm more and more inclined to forget about IE error pages): let's keep them 512 and not make them 90000 :-P
On Friday, December 14, 2012 9:42:01 PM UTC+1, Massimo Di Pierro wrote: > > This is a problem. How about injecting more characters instead of less. > How about an image encoded in ascii? > > On Friday, 14 December 2012 13:44:24 UTC-6, Niphlod wrote: >> >> problem with older browser is : retrieve a working copy of it..... >> However, http://core.trac.wordpress.org/ticket/8942 and the following >> http://www.clintharris.net/2009/ie-512-byte-error-pages-and-wordpress/, >> http://support.microsoft.com/kb/294807 seems to point in the direction >> of < 7. >> Others sites include IE7 just referencing the "friendly error pages" item. >> >> Unfortunately it seems that in IE8 the problem persists (just checked): >> friendly error page kicks in. >> >> However, I'm saying: >> - the ticket page in rewrite.py is filled with characters already >> - we add them to the "temporarily down for maintenance" in main.py >> instead of injecting them on the HTTP() method, that can be (and its >> being) used also for interacting with non-browser clients. >> Cons: if anyone is doing >> raise HTTP(404, 'item not found') >> it won't display on IE. I'm positive though that if anyone is doing that >> an error "item not found" is not very much more informative than the >> "friendly page" of IE, and if it's needed "badly" a custom error page is >> prepared (and returned) >> >> PS: with gzip enabled it doesn't work anyway (meaning right now adding >> 512 "x" doesn't work). >> >> The only trick is resorting to HTTP(404, [something]) to skip the >> injecting feature.... >> >> --
