my issue is that there will never be any incentive for sites to clean themselves up as long as browsers ignore the problems (This particular problem is not helped either by IIS5 not enforcing compliance of script output).

This then puts pressure on proxy vendors to follow the lead of the browsers, and basically ignore / work around the problems, or attempt to clean up the response.

This is the spawning ground of security problems.

I can see why a browser would do this - you don't want to be the only browser on the block to not work with a site.  But it's bad for the web.

Even if the browser showed the page but popped a warning dialog would be miles better, that would then provide some incentive to the site operators to fix such problems.

Maybe a recommendation for the RFC?  It's probably already in there, although I looked through p1-messaging-07, esp S 4.2, and Appendix A, and I couldn't see any requirements for what a receiver of broken headers must do.

Regards

Adrien


Adrian Chadd wrote:
On Thu, Jul 23, 2009, Adrien de Croy wrote:

  
PHP Warning:  PHP Startup: sdo: Unable to initialize module
Module compiled with module API=20060613, debug=0, thread-safety=1
PHP    compiled with module API=20050922, debug=0, thread-safety=1
These options need to match
in Unknown on line 0
    

Hah nice!

  
Normally this wouldn't be particularly interesting - just another broken 
site.  However all the browsers I tested swallowed this without 
complaining and displayed the body.  I tested IE8, Chrome, FF3.5 and 
Opera 9.6.4.  Each of the lines in the response was terminated by CRLF 
(not bare LF), so I'm struggling to see how anyone can interpret the PHP 
warning as anything resembling a valid header (even wrapped, since no 
leading WS).

Isn't this a potentially serious security problem?

It's hard to be the only proxy that decides to demonstrate how broken 
this site is - customers don't understand....
    

I've been seeing other random non-header stuff in HTTP reply headers.
Squid also complains and iirc drop the request as invalid by default.

HTTP/1.1 200 OK                                                                                                                                                    
Content-Type: image/jpeg                                                                                                                                           
Vary: Accept-Encoding                                                                                                                                              
Accept_170C_49EDDAC0                                                                                                                                               
expires: Thu, 15 Apr 2011 20:00:00 GMT                                                                                                                             
Content-Length: 5900                                                                                                                                               
Date: Mon, 13 Jul 2009 08:17:12 GMT                                                                                                                                
Connection: close                                                                                                                                                  
age: 0                                                                                                                                                             
X-Cache: HIT

I'd love to know what generates that.



Adrian


  

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com