Re: Truncated health check response from real servers

Hello Willy, Krzysztof.

On 13 February 2010 10:40, Willy Tarreau <w#1wt.eu> wrote:
> On Fri, Feb 12, 2010 at 05:47:41PM +0100, Krzysztof Olędzki wrote:
>> There are several issues with the fix:
>>
>>  - we need to check if connection is not closed, as it is pointless to
>> use MSG_PEEK and restarting such check if there is no more data we are
>> able to read
>
> Indeed, with MSG_PEEK we have no way to tell the connection was closed.

For the time being, I've hacked together a patch to get our customer up and running.

I've allocated a new static character buffer, to store the intermediate results from the real server. I'm relying on recv() returning a length of 0 to indicate the server has closed the connection - not sure if that's a reliable method, but it seems to be repeatable.

>>  - some servers return empty description so increasing minimum response
>> length prevents haproxy from accepting such checks. Of course, if you
>> are not using such server, it should be safe to do it in your locally
>> patched version, but we mustn't do it on a public version.
>
> In fact, we should re-parse the response each time we call recv(). As
> long as we don't find a complete response, we can wait. This still
> implies a non-trivial change to current code.

I decided not to run the content check for every received packet, as I couldn't see an easy way to deal with the case where the string to match is split between two packets.

Nick.

-- 
Nick Chalk.

Loadbalancer.org Ltd.
Phone: +44 (0)870 443 8779
http://www.loadbalancer.org/