is anybody using request.restful *and* needs the 512 bytes in a restful response? i'm inclined to only skip those bytes for restful requests (because they are usually not displayed by browsers).
thanks, cfh On Friday, December 14, 2012 2:48:39 PM UTC-8, Niphlod wrote: > > 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.... >>> >>> --
