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/