Re: Truncated health check response from real servers

> Indeed it never made it in. Each time I look at it, I realize that
> cleaning it up and fixing it will take more time than what I have
> available to work on it :-/

I can understand that completely. :)

Actually, I am not that much interested in the patch per-se, I would just like to check the body of the check-response and compare it to a string for more reliable checks. I have included my original mail (and reasoning) on the subject below. It's not on top of my priority list right now either, still... sooner or later we might get bitten by it.

I'd love to help out coding, but sockets and C++ are not my strong points (though I am comfortable in C). I can help with testing though if needed. Let me know if it helps and if/when you find time for this. :)

Or, if you wish, I can take Nick's patch and extract just the parts with checking the response body? Can you point out some of the errors so I can avoid them?

Thanks,

Anze

On Friday 12 March 2010, 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?
>
> Thanks,
>
> Anze
>

On Thursday 08 July 2010, Willy Tarreau wrote:
> On Wed, Jul 07, 2010 at 11:37:48AM +0200, Anze wrote:
> > Hi all,
> >
> > We have tried upgrading our haproxy version to 1.4.8 and found than this
> > configuration setting fails:
> > http-check expect string check_is_ok
> > with message:
> > 'http-check' only supports 'disable-on-404'
> >
> > I guess the patch never made it to stable (yet?). Are there any plans to
> > add it to the trunk?
>
> Indeed it never made it in. Each time I look at it, I realize that
> cleaning it up and fixing it will take more time than what I have
> available to work on it :-/
>
> It's still available online though, but I would really not run it
> if I were you, as it still lacks some memory bounds checkings.
>
> Regards,
> Willy
>
Received on 2010/07/09 01:48