[PATCH] DOC: internals: Fix spelling errors in filters.txt

[Miroslav Zagorac]

Hello,

here is attached the patch that corrects several spelling errors in 
doc/internals/filters.txt document.


If the errors have already been corrected, I apologize.  :)


Best regards,

--
Zaga

What can change the nature of a man?
>From 6c40e5748a81bd56a115c7834cdf08147d312d86 Mon Sep 17 00:00:00 2001
From: Miroslav Zagorac 
Date: Thu, 26 Mar 2020 20:45:04 +0100
Subject: [PATCH] DOC: internals: Fix spelling errors in filters.txt

---
 doc/internals/filters.txt | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/doc/internals/filters.txt b/doc/internals/filters.txt
index cd3988fbb..5e9b58e56 100644
--- a/doc/internals/filters.txt
+++ b/doc/internals/filters.txt
@@ -54,7 +54,7 @@ places, mainly around channel analyzers. Their purpose is to allow filters to
 be involved in the data processing, from the stream creation/destruction to
 the data forwarding. Depending of what it should do, a filter can implement all
 or part of these callbacks. For now, existing callbacks are focused on
-streams. But futur improvements could enlarge filters scope. For example, it
+streams. But future improvements could enlarge filters scope. For example, it
 could be useful to handle events at the connection level.
 
 In HAProxy configuration file, a filter is declared in a proxy section, except
@@ -84,7 +84,7 @@ filters are also chained, frontend ones called first. Even if the filters
 processing is serialized, each filter will bahave as it was alone (unless it was
 developed to be aware of other filters). For all that, some constraints are
 imposed to filters, especially when data exchanged between the client and the
-server are processed. We will dicuss again these constraints when we will tackle
+server are processed. We will discuss again these constraints when we will tackle
 the subject of writing a filter.
 
 
@@ -122,11 +122,11 @@ The list of available filters is reported by 'haproxy -vv':
 Multiple filter lines can be used in a proxy section to chain filters. Filters
 will be called in the declaration order.
 
-Some filters can support implicit declarartions in certain circumstances
+Some filters can support implicit declarations in certain circumstances
 (without the filter line). This is not recommended for new features but are
 useful for existing ones moved in a filter, for backward compatibility
-reasons. Implicit declarartions are supported when there is only one filter used
-on a proxy. When several filters are used, explicit declarartions are mandatory.
+reasons. Implicit declarations are supported when there is only one filter used
+on a proxy. When several filters are used, explicit declarations are mandatory.
 The HTTP compression filter is one of these filters. Alone, using 'compression'
 keywords is enough to use it. But when at least a second filter is used, a
 filter line must be added.
@@ -283,7 +283,7 @@ the structure 'stream', the field 'strm_flt' is the state of all filter
 instances attached to a stream:
 
 /*
- * Structure reprensenting the "global" state of filters attached to a
+ * Structure representing the "global" state of filters attached to a
  * stream.
  */
 struct strm_flt {
@@ -302,7 +302,7 @@ Filter instances attached to a stream are stored in the field
 'strm_flt.filters', each instance is of type 'struct filter *':
 
 /*
- * Structure reprensenting a filter instance attached to a stream
+ * Structure representing a filter instance attached to a stream
  *
  * 2D-Array fields are used to store info per channel. The first index
  * stands for the request channel, and the second one for the response
@@ -659,7 +659,7 @@ For example:
 The main purpose of filters is to take part in the channels analyzing. To do so,
 there is 2 callbacks, 'flt_ops.channel_pre_analyze' and
 'flt_ops.channel_post_analyze', called respectively before and after each
-analyzer attached to a channel, execpt analyzers responsible for the data
+analyzer attached to a channel, except analyzers responsible for the data
 parsing/forwarding (TCP or HTTP data). Concretely, on the request channel, these
 callbacks could be called before following analyzers:
 
-- 
2.20.1

Re: [PATCHES] dns related

[PiBa-NL]

Hi Baptiste,

Op 26-3-2020 om 12:46 schreef William Lallemand:

On Wed, Mar 25, 2020 at 11:15:37AM +0100, Baptiste wrote:

Hi there,

A couple of patches here to cleanup and fix some bugs introduced
by 13a9232ebc63fdf357ffcf4fa7a1a5e77a1eac2b.

Baptiste

Thanks Baptiste, merged.



Thanks for this one.
Question though, are you still working on making a non-existing server 
template go into 'resolution' state?


See below/attached picture with some details.. (or see 
https://www.mail-archive.com/haproxy@formilux.org/msg36373.html )

Regards,
PiBa-NL (Pieter)

Re: [PATCH] MINOR: ssl: skip self issued CA in cert chain for ssl_ctx

[William Lallemand]

On Thu, Mar 26, 2020 at 02:39:03PM +0100, Emmanuel Hocdet wrote:
> 
> > Le 26 mars 2020 à 14:11, Илья Шипицин  a écrit :
> > 
> > 
> > 
> > чт, 26 мар. 2020 г. в 17:27, Emmanuel Hocdet  > >:
> > 
> > > Le 26 mars 2020 à 13:02, Илья Шипицин  > > > a écrit :
> > > 
> > > RootCA is needed if you send cross certificate as well.
> > > 
> > > It is very rare but legitimate case
> > 
> > It’s only for self issued CA, it should be safe, right?
> > 
> > I do not know what "yes" or "no" would mean :)
> > 
> > by cross certificate I mean chain like that
> > 
> > server cert --> intermediate CA --> root CA --> cross certificate
> > 
> > https://knowledge.digicert.com/generalinformation/INFO2523.html 
> > 
> > 
> > root CA is self issued
> 
> self issued CA is a root CA
> Subject == Issuer
> 
> In your example:
> 
> Subject: C = US, O = "thawte, Inc.", OU = Certification Services Division, OU 
> = "(c) 2006 thawte, Inc. - For authorized use only", CN = thawte Primary Root 
> CA
> Issuer: C = ZA, ST = Western Cape, L = Cape Town, O = Thawte Consulting cc, 
> OU = Certification Services Division, CN = Thawte Premium Server CA, 
> emailAddress = premium-ser...@thawte.com 

After some thinking and discussing with people involved in this part of
HAProxy. I'm not feeling very confortable with setting this behavior by
default, on top on that the next version is an LTS so its not a good
idea to change this behavior yet. I think in most case it won't be a
problem but it would be better if it's enabled by an option in the
global section.

-- 
William Lallemand

Re: [PATCH] MINOR: ssl: skip self issued CA in cert chain for ssl_ctx

[Emmanuel Hocdet]

> Le 26 mars 2020 à 14:11, Илья Шипицин  a écrit :
> 
> 
> 
> чт, 26 мар. 2020 г. в 17:27, Emmanuel Hocdet  >:
> 
> > Le 26 mars 2020 à 13:02, Илья Шипицин  > > a écrit :
> > 
> > RootCA is needed if you send cross certificate as well.
> > 
> > It is very rare but legitimate case
> 
> It’s only for self issued CA, it should be safe, right?
> 
> I do not know what "yes" or "no" would mean :)
> 
> by cross certificate I mean chain like that
> 
> server cert --> intermediate CA --> root CA --> cross certificate
> 
> https://knowledge.digicert.com/generalinformation/INFO2523.html 
> 
> 
> root CA is self issued

self issued CA is a root CA
Subject == Issuer

In your example:

Subject: C = US, O = "thawte, Inc.", OU = Certification Services Division, OU = 
"(c) 2006 thawte, Inc. - For authorized use only", CN = thawte Primary Root CA
Issuer: C = ZA, ST = Western Cape, L = Cape Town, O = Thawte Consulting cc, OU 
= Certification Services Division, CN = Thawte Premium Server CA, emailAddress 
= premium-ser...@thawte.com 

Re: [PATCH] MINOR: ssl: skip self issued CA in cert chain for ssl_ctx

[Илья Шипицин]

чт, 26 мар. 2020 г. в 17:27, Emmanuel Hocdet :

>
> > Le 26 mars 2020 à 13:02, Илья Шипицин  a écrit :
> >
> > RootCA is needed if you send cross certificate as well.
> >
> > It is very rare but legitimate case
>
> It’s only for self issued CA, it should be safe, right?
>

I do not know what "yes" or "no" would mean :)

by cross certificate I mean chain like that

server cert --> intermediate CA --> root CA --> cross certificate

https://knowledge.digicert.com/generalinformation/INFO2523.html

root CA is self issued

Re: [PATCH] MINOR: ssl: skip self issued CA in cert chain for ssl_ctx

[Emmanuel Hocdet]

> Le 26 mars 2020 à 13:02, Илья Шипицин  a écrit :
> 
> RootCA is needed if you send cross certificate as well.
> 
> It is very rare but legitimate case

It’s only for self issued CA, it should be safe, right?

Re: [PATCH] MINOR: ssl: skip self issued CA in cert chain for ssl_ctx

[Илья Шипицин]

RootCA is needed if you send cross certificate as well.

It is very rare but legitimate case

On Thu, Mar 26, 2020, 4:56 PM William Lallemand 
wrote:

> On Wed, Mar 25, 2020 at 10:46:10AM +0100, Emmanuel Hocdet wrote:
> >
> > Hi,
> > Patch rebase from master.
> >
> > > Le 6 mars 2020 à 17:06, Emmanuel Hocdet  a écrit :
> > >
> > > Hi,
> > >
> > >
> > > Patch proposal.
> > > I will update the documentation if this feature is approved.
> > >
> >
>
> I don't see any case where we would need to the send the RootCA, but
> it changes somehow the previous behavior which was to send everything.
> I'm merging it, if someone still want the previous behavior we could add
> a configuration option.
>
> Could you provide a new patch with an update of the documentation as you
> suggested? Thanks
> --
> William Lallemand
>
>

Re: [PATCH] MINOR: ssl: skip self issued CA in cert chain for ssl_ctx

[William Lallemand]

On Wed, Mar 25, 2020 at 10:46:10AM +0100, Emmanuel Hocdet wrote:
> 
> Hi,
> Patch rebase from master.
> 
> > Le 6 mars 2020 à 17:06, Emmanuel Hocdet  a écrit :
> > 
> > Hi,
> > 
> > 
> > Patch proposal.
> > I will update the documentation if this feature is approved.
> > 
> 

I don't see any case where we would need to the send the RootCA, but
it changes somehow the previous behavior which was to send everything.
I'm merging it, if someone still want the previous behavior we could add
a configuration option.

Could you provide a new patch with an update of the documentation as you
suggested? Thanks
-- 
William Lallemand

Re: [PATCHES] dns related

[William Lallemand]

On Wed, Mar 25, 2020 at 11:15:37AM +0100, Baptiste wrote:
> Hi there,
> 
> A couple of patches here to cleanup and fix some bugs introduced
> by 13a9232ebc63fdf357ffcf4fa7a1a5e77a1eac2b.
> 
> Baptiste

Thanks Baptiste, merged.


-- 
William Lallemand

Re: [RFC] BUG/MEDIUM: Checks: support for HTTP health checks with POST and data corrupted by extra connection close

[Aleksandar Lazic]

On 26.03.20 09:42, Willy Tarreau wrote:

On Thu, Mar 26, 2020 at 09:25:31AM +0100, Christopher Faulet wrote:

It is a good idea. For now, I have only few idea though. For the header
part, it must not be a raw block. Because it will be really hard to keep the
same syntax with the HTX. I propose to keep same syntax than http-request
rules :

http-check add-header  

And later :

http-check set-header  
http-check del-header 
http-check replace-header   
http-check replace-value   


I don't think we'll need to perform such operations in health checks because
they're normally only useful for real traffic. Here everything is built from
scratch so deleting a header or replacing it will be of very limited use, it
just means they would have been added by a previous rule. Also thinking about
this when combined with multiple requests gives me a headache :-)


Well I think that could be required when the backend have different vhosts
and ssl-vhosts.

Can we add request|respone to make it a little bit clear when which header will
be set.

# set session cookie for example
http-check request set-header  |
http-check request set-sni  |

http-check response expect 
# I'm not sure if there is a use case for that
http-check response del-header 


What I like is to be able to define a check backend and use the track keyword
for checks.

http://cbonte.github.io/haproxy-dconv/2.2/configuration.html#5.2-track

Will this be also available in the first implementation?


Another idea could be to have a syntax similar to the HTTP return action :

http-check hdr   hdr   string 

or


why not both => AND but only one is usable in one check sequence?


http-check hdr   hdr   file 


These ones do seem like good ideas. They continue to allow to fully
define a check in a simple statement. And maybe later when we start
to think about sending check sequences they will be very convenient
because each line could define an entire request (possibly reusing
parts from the previous response if needed).


The request URI is passed on the "option httpchk" line. But, maybe the
method, the path and the version may also be defined on such line.


Agreed.


There are many other problems to deal with. But it is a first step. The
content-length must be automatically deduced when a body is defined.


Fully agreed!


For
current versions, the connection header must also be added the same way it
is done today.


Sure. I'd say it's a "detail" in that it's not visible from the users' end.


During my refactoring, I can try to first work on a way to support such
syntax on current versions. But we must be sure to have the right syntax
first. It is the harder part :)


Yes, that's exactly my point as well. If we figure the long-term picture,
we can narrow it down for a first implementation.

Willy

Re: [RFC] BUG/MEDIUM: Checks: support for HTTP health checks with POST and data corrupted by extra connection close

[Christopher Faulet]

Le 26/03/2020 à 09:24, Kiran Gavali a écrit :

Thank you Christopher and Willy for your responses !

We have discussed the resolution for the issue on GitHub at following link: 
https://github.com/haproxy/haproxy/issues/16
However to further explain the patch fix, we have introduced new options, "header" and 
"body" in http-check directive. Based on the content for these options configured in haproxy.cfg 
and if expect option is also configured for http-check, the header is added to a buffer followed by the 
"Connection: close" string which is further followed by the body.
For cases, when either header or body or both is not configured in haproxy.cfg, 
we have used default values to create the data packet in the buffer.
We would definitely update the documentation once the patch is finalized and 
therefore shared it with RFC tag.

Ah, ok. I understand now. I missed the RFC tag in the email subject, sorry :)



To answer your  query on reg-test, We have performed regression testing of the 
patch using the RT suite available at our end. We can share with you the test 
report, if required. However, if there is any community RT suite that you would 
like us to follow, please do let me know.



About the regression tests, we use varnishtest (https://github.com/vtest/VTest). 
All our tests are placed in the "reg-tests" subdirectory. Here is a 
documentation to write VTC tests: 
https://varnish-cache.org/docs/trunk/reference/vtc.html.


To run tests, you may use the script "scripts/run-regtests.sh" or the "make 
reg-tests" command.



As far as the relevance of this patch is concerned, considering the planned 
http-check refactoring at your end, we were already aware that the patch might 
not be merged due to the  fact that the check system is currently being 
reworked to support muxes for HTTP/1 and HTTP/2 so that there are better checks 
in 2.2



As Willy said, have a solution for current versions is also important. But the 
syntax must be compatible with the next one. This part must be discussed first.


--
Christopher Faulet

Re: [RFC] BUG/MEDIUM: Checks: support for HTTP health checks with POST and data corrupted by extra connection close

[Willy Tarreau]

On Thu, Mar 26, 2020 at 09:25:31AM +0100, Christopher Faulet wrote:
> It is a good idea. For now, I have only few idea though. For the header
> part, it must not be a raw block. Because it will be really hard to keep the
> same syntax with the HTX. I propose to keep same syntax than http-request
> rules :
> 
> http-check add-header  
> 
> And later :
> 
> http-check set-header  
> http-check del-header 
> http-check replace-header   
> http-check replace-value   

I don't think we'll need to perform such operations in health checks because
they're normally only useful for real traffic. Here everything is built from
scratch so deleting a header or replacing it will be of very limited use, it
just means they would have been added by a previous rule. Also thinking about
this when combined with multiple requests gives me a headache :-)

> Another idea could be to have a syntax similar to the HTTP return action :
> 
> http-check hdr   hdr   string 
> 
> or
> 
> http-check hdr   hdr   file 

These ones do seem like good ideas. They continue to allow to fully
define a check in a simple statement. And maybe later when we start
to think about sending check sequences they will be very convenient
because each line could define an entire request (possibly reusing
parts from the previous response if needed).

> The request URI is passed on the "option httpchk" line. But, maybe the
> method, the path and the version may also be defined on such line.

Agreed.

> There are many other problems to deal with. But it is a first step. The
> content-length must be automatically deduced when a body is defined.

Fully agreed!

> For
> current versions, the connection header must also be added the same way it
> is done today.

Sure. I'd say it's a "detail" in that it's not visible from the users' end.

> During my refactoring, I can try to first work on a way to support such
> syntax on current versions. But we must be sure to have the right syntax
> first. It is the harder part :)

Yes, that's exactly my point as well. If we figure the long-term picture,
we can narrow it down for a first implementation.

Willy

RE: [RFC] BUG/MEDIUM: Checks: support for HTTP health checks with POST and data corrupted by extra connection close

[Kiran Gavali]

Thank you Christopher and Willy for your responses !

We have discussed the resolution for the issue on GitHub at following link: 
https://github.com/haproxy/haproxy/issues/16
However to further explain the patch fix, we have introduced new options, 
"header" and "body" in http-check directive. Based on the content for these 
options configured in haproxy.cfg and if expect option is also configured for 
http-check, the header is added to a buffer followed by the "Connection: close" 
string which is further followed by the body.
For cases, when either header or body or both is not configured in haproxy.cfg, 
we have used default values to create the data packet in the buffer.
We would definitely update the documentation once the patch is finalized and 
therefore shared it with RFC tag.

To answer your  query on reg-test, We have performed regression testing of the 
patch using the RT suite available at our end. We can share with you the test 
report, if required. However, if there is any community RT suite that you would 
like us to follow, please do let me know.

As far as the relevance of this patch is concerned, considering the planned 
http-check refactoring at your end, we were already aware that the patch might 
not be merged due to the  fact that the check system is currently being 
reworked to support muxes for HTTP/1 and HTTP/2 so that there are better checks 
in 2.2

Thanks,
Kiran Gavali

-Original Message-
From: Willy Tarreau [mailto:w...@1wt.eu]
Sent: Thursday, March 26, 2020 1:07 PM
To: Christopher Faulet 
Cc: Kiran Gavali ; haproxy@formilux.org; Shivharsh 
Singh ; Priya Ranjan 
; Ramanpreet Singh Bakshi 

Subject: Re: [RFC] BUG/MEDIUM: Checks: support for HTTP health checks with POST 
and data corrupted by extra connection close

Hi Christopher,

On Thu, Mar 26, 2020 at 07:40:06AM +0100, Christopher Faulet wrote:
> Thanks ! However there are many problems with your patch. First there
> is no commit message. You must explain what is exactly the problem and
> how you fix it. Then, the documentation must be updated. You
> introduced 2 new options without any explanation. Without these info,
> it is really hard to figure out what the patch do.

I noticed these as well, thanks for pointing out before me :-)

> But reading how headers and body buffers are inserted in the request,
> I suspect some bugs. A reg-test is probably necessary to validate such
> feature.

Yes that would indeed be useful.

> But, don't bother for now submitting a new patch. I'm currently
> refactoring the tcp-checks. But on my todo list, the next big step is
> the http-check refactoring. It is painful but I hope to finish the
> refactoring of the checks for the 2.2.0.

My main concern is the backward compatibility. Kiran's patch is small enough to 
be backported, so that might constitute a possible solution for existing 
setups. However we cannot afford to do that if it works differently than what 
we'll have in the final release. As such I think it's important to quickly 
figure how we want such a separate body part to be *configured* and make sure 
that it's done the same in your new version and in Kiran's patch. If so, then 
we could imagine merging it early to have it backported so that it's ultimately 
replaced in 2.2 by your work once ready.

What do you think ?

Thanks,
Willy

 The contents of this e-mail and any attachment(s) are confidential and 
intended for the named recipient(s) only. It shall not attach any liability on 
the originator or NECTI or its affiliates. Any views or opinions presented in 
this email are solely those of the author and may not necessarily reflect the 
opinions of NECTI or its affiliates. Any form of reproduction, dissemination, 
copying, disclosure, modification, distribution and / or publication of this 
message without the prior written consent of the author of this e-mail is 
strictly prohibited. If you have received this email in error please delete it 
and notify the sender immediately.

Re: [RFC] BUG/MEDIUM: Checks: support for HTTP health checks with POST and data corrupted by extra connection close

[Christopher Faulet]

Le 26/03/2020 à 08:36, Willy Tarreau a écrit :

Hi Christopher,

On Thu, Mar 26, 2020 at 07:40:06AM +0100, Christopher Faulet wrote:

Thanks ! However there are many problems with your patch. First there is no
commit message. You must explain what is exactly the problem and how you fix
it. Then, the documentation must be updated. You introduced 2 new options
without any explanation. Without these info, it is really hard to figure out
what the patch do.


I noticed these as well, thanks for pointing out before me :-)


But reading how headers and body buffers are inserted in
the request, I suspect some bugs. A reg-test is probably necessary to
validate such feature.


Yes that would indeed be useful.


But, don't bother for now submitting a new patch. I'm currently refactoring
the tcp-checks. But on my todo list, the next big step is the http-check
refactoring. It is painful but I hope to finish the refactoring of the
checks for the 2.2.0.


My main concern is the backward compatibility. Kiran's patch is small
enough to be backported, so that might constitute a possible solution
for existing setups. However we cannot afford to do that if it works
differently than what we'll have in the final release. As such I think
it's important to quickly figure how we want such a separate body part
to be *configured* and make sure that it's done the same in your new
version and in Kiran's patch. If so, then we could imagine merging it
early to have it backported so that it's ultimately replaced in 2.2 by
your work once ready.

What do you think ?



It is a good idea. For now, I have only few idea though. For the header part, it 
must not be a raw block. Because it will be really hard to keep the same syntax 
with the HTX. I propose to keep same syntax than http-request rules :


http-check add-header  

And later :

http-check set-header  
http-check del-header 
http-check replace-header   
http-check replace-value   

Another idea could be to have a syntax similar to the HTTP return action :

http-check hdr   hdr   string 

or

http-check hdr   hdr   file 

The request URI is passed on the "option httpchk" line. But, maybe the method, 
the path and the version may also be defined on such line.


There are many other problems to deal with. But it is a first step. The 
content-length must be automatically deduced when a body is defined. For current 
versions, the connection header must also be added the same way it is done today.


During my refactoring, I can try to first work on a way to support such syntax 
on current versions. But we must be sure to have the right syntax first. It is 
the harder part :)


--
Christopher Faulet

Re: [RFC] BUG/MEDIUM: Checks: support for HTTP health checks with POST and data corrupted by extra connection close

[Willy Tarreau]

Hi Christopher,

On Thu, Mar 26, 2020 at 07:40:06AM +0100, Christopher Faulet wrote:
> Thanks ! However there are many problems with your patch. First there is no
> commit message. You must explain what is exactly the problem and how you fix
> it. Then, the documentation must be updated. You introduced 2 new options
> without any explanation. Without these info, it is really hard to figure out
> what the patch do.

I noticed these as well, thanks for pointing out before me :-)

> But reading how headers and body buffers are inserted in
> the request, I suspect some bugs. A reg-test is probably necessary to
> validate such feature.

Yes that would indeed be useful.

> But, don't bother for now submitting a new patch. I'm currently refactoring
> the tcp-checks. But on my todo list, the next big step is the http-check
> refactoring. It is painful but I hope to finish the refactoring of the
> checks for the 2.2.0.

My main concern is the backward compatibility. Kiran's patch is small
enough to be backported, so that might constitute a possible solution
for existing setups. However we cannot afford to do that if it works
differently than what we'll have in the final release. As such I think
it's important to quickly figure how we want such a separate body part
to be *configured* and make sure that it's done the same in your new
version and in Kiran's patch. If so, then we could imagine merging it
early to have it backported so that it's ultimately replaced in 2.2 by
your work once ready.

What do you think ?

Thanks,
Willy

Re: [RFC] BUG/MEDIUM: Checks: support for HTTP health checks with POST and data corrupted by extra connection close

[Christopher Faulet]

Le 23/03/2020 à 13:24, Kiran Gavali a écrit :

Hello Mr. Willy Tarreau ,

I have created a patch to resolve following issue 
"https://github.com/haproxy/haproxy/issues/16; .
And I have generated the patch files by following the steps defined in 
"https://github.com/haproxy/haproxy/blob/master/CONTRIBUTING; document.
Request you to please review the patch and provide your feedback.



Hi,

Thanks ! However there are many problems with your patch. First there is no 
commit message. You must explain what is exactly the problem and how you fix it. 
Then, the documentation must be updated. You introduced 2 new options without 
any explanation. Without these info, it is really hard to figure out what the 
patch do. But reading how headers and body buffers are inserted in the request, 
I suspect some bugs. A reg-test is probably necessary to validate such feature.


But, don't bother for now submitting a new patch. I'm currently refactoring the 
tcp-checks. But on my todo list, the next big step is the http-check 
refactoring. It is painful but I hope to finish the refactoring of the checks 
for the 2.2.0.


Regards,
--
Christopher Faulet