On Fri, Mar 12, 2010 at 09:32:16AM +0100, Anze wrote: > Hi! > > First of all: Willy Tarreau & others, thank you for a great piece of > software! > It just works. :) > > PHP has a bug when errors in PHP code do not always issue HTTP error status > code to be sent, but instead return status 200 > (http://bugs.php.net/bug.php?id=50921) > > The problem is that when haproxy calls check.php, the scrpt itself is not run > if there is an error in it (or in the includes it needs for the checks). So > this check is not really reliable. > > I know this is not really haproxy's problem (the bug is on the PHP side), but > reliability would be much higher if haproxy could compare the response body > to > some string (for instance, server must return "really ok" in request body). > That way the bug in interpreter could never cause a false positive. > > Example PHP script: > <? > // this fails: > call_some_undefined_function(); > // this is not executed: > echo "really ok" > ?> > > This fails silently and return an empty document (or document with error > description, depending on PHP config) with status 200. > > As a side note, that would also allow us to catch PHP configuration errors, > such as "short_tags" set to off - in which case the previous code would be > just listed (with status 200!), not executed. When compared to "really ok", > it > would fail. > > Any chance this can be done with haproxy?
It is possible with the patch that Nick Chalk recently posted in the thread "Truncated health check response from real servers". It is a rework of an older patch you might find references to on the net, with severak issues fixed and a properly working buffering so that servers which respond in multiple small chunks are correctly understood. If it works well, I'm thinking about integrating it into 1.4.2. You seem to be a good candidate to test it :-) Regards, Willy
