Re: regtests - with option http-use-htx

2019-01-08 Thread Frederic Lecaille

On 1/8/19 9:05 PM, PiBa-NL wrote:

Hi Frederic,

Op 8-1-2019 om 16:27 schreef Frederic Lecaille:

On 12/15/18 4:52 PM, PiBa-NL wrote:

Hi List, Willy,

Trying to run some existing regtests with added option: option 
http-use-htx


Using: HA-Proxy version 1.9-dev10-c11ec4a 2018/12/15

I get the below issues sofar:

 based on /reg-tests/connection/b0.vtc
Takes 8 seconds to pass, in a slightly modified manor 1.1 > 2.0 
expectation for syslog. This surely needs a closer look?

#    top  TEST ./htx-test/connection-b0.vtc passed (8.490)

 based on /reg-tests/stick-table/b1.vtc
Difference here is the use=1 vs use=0 , maybe that is better, but 
then the 'old' expectation seems wrong, and the bug is the case 
without htx?


Note that the server s1 never responds.

Furthermore, c1 client is run with -run argument.
This means that we wait for its termination before running accessing CLI.
Then we check that there is no consistency issue with the stick-table:

if the entry has expired we get only this line:

    table: http1, type: ip, size:1024, used:0

if not we get these two lines:

    table: http1, type: ip, size:1024, used:1
    .*    use=0 ...

here used=1 means there is still an entry in the stick-table, and 
use=0 means it is not currently in use (I guess this is because the 
client has closed its connection).


I do not reproduce your issue with this script both on Linux and 
FreeBSD 11 both with or without htx.
Did you try with the 'old' development version (1.9-dev10-c11ec4a 
2018/12/15), i think in current version its already fixed see my own 
test results also below.


No. I have not tested with the previous dev versions.
I wanted to clarify the logic behind the test. I agree perhaps there is
not enough comments in this script.

 h1    0.0 CLI recv|0x8026612c0: key=127.0.0.1 use=1 exp=0 gpt0=0 
gpc0=0 gpc0_rate(1)=0 conn_rate(1)=1 http_req_cnt=1 
http_req_rate(1)=1 http_err_cnt=0 http_err_rate(1)=0

 h1    0.0 CLI recv|
 h1    0.0 CLI expect failed ~ "table: http1, type: ip, 
size:1024, used:(0|1\n0x[0-9a-f]*: key=127\.0\.0\.1 use=0 exp=[0-9]* 
gpt0=0 gpc0=0 gpc0_rate\(1\)=0 conn_rate\(1\)=1 
http_req_cnt=1 http_req_rate\(1\)=1 http_err_cnt=0 
http_err_rate\(1\)=0)\n$"


Regards,

PiBa-NL (Pieter)



I tried again today with both 2.0-dev0-251a6b7 and 1.9.0-8223050 and 
1.9-dev10-c11ec4a :


HA-Proxy version 2.0-dev0-251a6b7 2019/01/08 - https://haproxy.org/
## Without HTX
#    top  TEST ./PB-TEST/2018/connection-b0.vtc passed (0.146)
#    top  TEST ./PB-TEST/2018/stick-table-b1.vtc passed (0.127)
0 tests failed, 0 tests skipped, 2 tests passed
## With HTX
#    top  TEST ./PB-TEST/2018/connection-b0.vtc passed (0.147)
#    top  TEST ./PB-TEST/2018/stick-table-b1.vtc passed (0.127)
0 tests failed, 0 tests skipped, 2 tests passed


HA-Proxy version 1.9.0-8223050 2018/12/19 - https://haproxy.org/
## Without HTX
#    top  TEST ./PB-TEST/2018/connection-b0.vtc passed (0.150)
#    top  TEST ./PB-TEST/2018/stick-table-b1.vtc passed (0.128)
0 tests failed, 0 tests skipped, 2 tests passed
## With HTX
#    top  TEST ./PB-TEST/2018/connection-b0.vtc passed (0.148)
#    top  TEST ./PB-TEST/2018/stick-table-b1.vtc passed (0.127)
0 tests failed, 0 tests skipped, 2 tests passed



Ok.



HA-Proxy version 1.9-dev10-c11ec4a 2018/12/15
Copyright 2000-2018 Willy Tarreau 
## Without HTX
#    top  TEST ./PB-TEST/2018/connection-b0.vtc passed (0.146)
#    top  TEST ./PB-TEST/2018/stick-table-b1.vtc passed (0.127)
0 tests failed, 0 tests skipped, 2 tests passed
## With HTX
#    top  TEST ./PB-TEST/2018/connection-b0.vtc passed (8.646)
*    top   0.0 TEST ./PB-TEST/2018/stick-table-b1.vtc starting
 h1    0.0 CLI recv|# table: http1, type: ip, size:1024, used:1
 h1    0.0 CLI recv|0x80262a200: key=127.0.0.1 use=1 exp=0 gpt0=0 
gpc0=0 gpc0_rate(1)=0 conn_rate(1)=1 http_req_cnt=1 
http_req_rate(1)=1 http_err_cnt=0 http_err_rate(1)=0

 h1    0.0 CLI recv|
 h1    0.0 CLI expect failed ~ "table: http1, type: ip, size:1024, 
used:(0|1\n0x[0-9a-f]*: key=127\.0\.0\.1 use=0 exp=[0-9]* gpt0=0 gpc0=0 
gpc0_rate\(1\)=0 conn_rate\(1\)=1 http_req_cnt=1 
http_req_rate\(1\)=1 http_err_cnt=0 http_err_rate\(1\)=0)\n$"

*    top   0.0 RESETTING after ./PB-TEST/2018/stick-table-b1.vtc
**   h1    0.0 Reset and free h1 haproxy 92940
#    top  TEST ./PB-TEST/2018/stick-table-b1.vtc FAILED (0.127) exit=2
1 tests failed, 0 tests skipped, 1 tests passed

With the 'old' 1.9-dev10 version and with HTX i can still reproduce the 
"passed (8.646)" and "use=1".. But both 1.9.0 and 2.0-dev don't show 
that behavior. I have not 'bisected' further, but i don't think there is 
anything to do a.t.m. regarding this old (already fixed) issue.


Good news.

Thanks Pieter.


Regards,

PiBa-NL (Pieter)




Regards.

Fred



Re: regtests - with option http-use-htx

2019-01-08 Thread PiBa-NL

Hi Frederic,

Op 8-1-2019 om 16:27 schreef Frederic Lecaille:

On 12/15/18 4:52 PM, PiBa-NL wrote:

Hi List, Willy,

Trying to run some existing regtests with added option: option 
http-use-htx


Using: HA-Proxy version 1.9-dev10-c11ec4a 2018/12/15

I get the below issues sofar:

 based on /reg-tests/connection/b0.vtc
Takes 8 seconds to pass, in a slightly modified manor 1.1 > 2.0 
expectation for syslog. This surely needs a closer look?

#    top  TEST ./htx-test/connection-b0.vtc passed (8.490)

 based on /reg-tests/stick-table/b1.vtc
Difference here is the use=1 vs use=0 , maybe that is better, but 
then the 'old' expectation seems wrong, and the bug is the case 
without htx?


Note that the server s1 never responds.

Furthermore, c1 client is run with -run argument.
This means that we wait for its termination before running accessing CLI.
Then we check that there is no consistency issue with the stick-table:

if the entry has expired we get only this line:

    table: http1, type: ip, size:1024, used:0

if not we get these two lines:

    table: http1, type: ip, size:1024, used:1
    .*    use=0 ...

here used=1 means there is still an entry in the stick-table, and 
use=0 means it is not currently in use (I guess this is because the 
client has closed its connection).


I do not reproduce your issue with this script both on Linux and 
FreeBSD 11 both with or without htx.
Did you try with the 'old' development version (1.9-dev10-c11ec4a 
2018/12/15), i think in current version its already fixed see my own 
test results also below.
 h1    0.0 CLI recv|0x8026612c0: key=127.0.0.1 use=1 exp=0 gpt0=0 
gpc0=0 gpc0_rate(1)=0 conn_rate(1)=1 http_req_cnt=1 
http_req_rate(1)=1 http_err_cnt=0 http_err_rate(1)=0

 h1    0.0 CLI recv|
 h1    0.0 CLI expect failed ~ "table: http1, type: ip, 
size:1024, used:(0|1\n0x[0-9a-f]*: key=127\.0\.0\.1 use=0 exp=[0-9]* 
gpt0=0 gpc0=0 gpc0_rate\(1\)=0 conn_rate\(1\)=1 
http_req_cnt=1 http_req_rate\(1\)=1 http_err_cnt=0 
http_err_rate\(1\)=0)\n$"


Regards,

PiBa-NL (Pieter)



I tried again today with both 2.0-dev0-251a6b7 and 1.9.0-8223050 and  
1.9-dev10-c11ec4a :


HA-Proxy version 2.0-dev0-251a6b7 2019/01/08 - https://haproxy.org/
## Without HTX
#    top  TEST ./PB-TEST/2018/connection-b0.vtc passed (0.146)
#    top  TEST ./PB-TEST/2018/stick-table-b1.vtc passed (0.127)
0 tests failed, 0 tests skipped, 2 tests passed
## With HTX
#    top  TEST ./PB-TEST/2018/connection-b0.vtc passed (0.147)
#    top  TEST ./PB-TEST/2018/stick-table-b1.vtc passed (0.127)
0 tests failed, 0 tests skipped, 2 tests passed


HA-Proxy version 1.9.0-8223050 2018/12/19 - https://haproxy.org/
## Without HTX
#    top  TEST ./PB-TEST/2018/connection-b0.vtc passed (0.150)
#    top  TEST ./PB-TEST/2018/stick-table-b1.vtc passed (0.128)
0 tests failed, 0 tests skipped, 2 tests passed
## With HTX
#    top  TEST ./PB-TEST/2018/connection-b0.vtc passed (0.148)
#    top  TEST ./PB-TEST/2018/stick-table-b1.vtc passed (0.127)
0 tests failed, 0 tests skipped, 2 tests passed


HA-Proxy version 1.9-dev10-c11ec4a 2018/12/15
Copyright 2000-2018 Willy Tarreau 
## Without HTX
#    top  TEST ./PB-TEST/2018/connection-b0.vtc passed (0.146)
#    top  TEST ./PB-TEST/2018/stick-table-b1.vtc passed (0.127)
0 tests failed, 0 tests skipped, 2 tests passed
## With HTX
#    top  TEST ./PB-TEST/2018/connection-b0.vtc passed (8.646)
*    top   0.0 TEST ./PB-TEST/2018/stick-table-b1.vtc starting
 h1    0.0 CLI recv|# table: http1, type: ip, size:1024, used:1
 h1    0.0 CLI recv|0x80262a200: key=127.0.0.1 use=1 exp=0 gpt0=0 
gpc0=0 gpc0_rate(1)=0 conn_rate(1)=1 http_req_cnt=1 
http_req_rate(1)=1 http_err_cnt=0 http_err_rate(1)=0

 h1    0.0 CLI recv|
 h1    0.0 CLI expect failed ~ "table: http1, type: ip, size:1024, 
used:(0|1\n0x[0-9a-f]*: key=127\.0\.0\.1 use=0 exp=[0-9]* gpt0=0 gpc0=0 
gpc0_rate\(1\)=0 conn_rate\(1\)=1 http_req_cnt=1 
http_req_rate\(1\)=1 http_err_cnt=0 http_err_rate\(1\)=0)\n$"

*    top   0.0 RESETTING after ./PB-TEST/2018/stick-table-b1.vtc
**   h1    0.0 Reset and free h1 haproxy 92940
#    top  TEST ./PB-TEST/2018/stick-table-b1.vtc FAILED (0.127) exit=2
1 tests failed, 0 tests skipped, 1 tests passed

With the 'old' 1.9-dev10 version and with HTX i can still reproduce the 
"passed (8.646)" and "use=1".. But both 1.9.0 and 2.0-dev don't show 
that behavior. I have not 'bisected' further, but i don't think there is 
anything to do a.t.m. regarding this old (already fixed) issue.


Regards,

PiBa-NL (Pieter)




Re: regtests - with option http-use-htx

2019-01-08 Thread Frederic Lecaille

On 12/15/18 4:52 PM, PiBa-NL wrote:

Hi List, Willy,

Trying to run some existing regtests with added option: option http-use-htx

Using: HA-Proxy version 1.9-dev10-c11ec4a 2018/12/15

I get the below issues sofar:

 based on /reg-tests/connection/b0.vtc
Takes 8 seconds to pass, in a slightly modified manor 1.1 > 2.0 
expectation for syslog. This surely needs a closer look?

#    top  TEST ./htx-test/connection-b0.vtc passed (8.490)

 based on /reg-tests/stick-table/b1.vtc
Difference here is the use=1 vs use=0 , maybe that is better, but then 
the 'old' expectation seems wrong, and the bug is the case without htx?


Note that the server s1 never responds.

Furthermore, c1 client is run with -run argument.
This means that we wait for its termination before running accessing CLI.
Then we check that there is no consistency issue with the stick-table:

if the entry has expired we get only this line:

table: http1, type: ip, size:1024, used:0

if not we get these two lines:

table: http1, type: ip, size:1024, used:1
.*use=0 ...

here used=1 means there is still an entry in the stick-table, and use=0 
means it is not currently in use (I guess this is because the client has 
closed its connection).


I do not reproduce your issue with this script both on Linux and FreeBSD 
11 both with or without htx.




 h1    0.0 CLI recv|0x8026612c0: key=127.0.0.1 use=1 exp=0 gpt0=0 
gpc0=0 gpc0_rate(1)=0 conn_rate(1)=1 http_req_cnt=1 
http_req_rate(1)=1 http_err_cnt=0 http_err_rate(1)=0

 h1    0.0 CLI recv|
 h1    0.0 CLI expect failed ~ "table: http1, type: ip, size:1024, 
used:(0|1\n0x[0-9a-f]*: key=127\.0\.0\.1 use=0 exp=[0-9]* gpt0=0 gpc0=0 
gpc0_rate\(1\)=0 conn_rate\(1\)=1 http_req_cnt=1 
http_req_rate\(1\)=1 http_err_cnt=0 http_err_rate\(1\)=0)\n$"


Regards,

PiBa-NL (Pieter)






Re: regtests - with option http-use-htx

2018-12-15 Thread Willy Tarreau
On Sat, Dec 15, 2018 at 05:18:08PM +0100, PiBa-NL wrote:
> > >  h1    0.0 CLI recv|0x8026612c0: key=127.0.0.1 use=1 exp=0 gpt0=0 
> > > gpc0=0
> > > gpc0_rate(1)=0 conn_rate(1)=1 http_req_cnt=1 
> > > http_req_rate(1)=1
> > > http_err_cnt=0 http_err_rate(1)=0
> > >  h1    0.0 CLI recv|
> > >  h1    0.0 CLI expect failed ~ "table: http1, type: ip, size:1024,
> > > used:(0|1\n0x[0-9a-f]*: key=127\.0\.0\.1 use=0 exp=[0-9]* gpt0=0 gpc0=0
> > > gpc0_rate\(1\)=0 conn_rate\(1\)=1 http_req_cnt=1
> > > http_req_rate\(1\)=1 http_err_cnt=0 http_err_rate\(1\)=0)\n$"
> > Hmmm here I think we're really hitting corner cases depending on whether
> > the tracked counters are released before or after the logs are emitted.
> > In the case of htx, the logs are emitted slightly later than before,
> > which may induce this. Quite honestly I'd be inclined to set use=[01]
> > here in the regex to cover the race condition that exists in both cases,
> > as there isn't any single good value. Christopher, are you also OK with
> > this ? I can do the patch if you're OK.
> Its not about emitting logs, its querying the stats admin socket,

Ah of course you're right, I recognize the output now!

> and even
> with a added 'delay 2' before doing so the results seem to show the same
> difference with/without htx. I don't think its a matter of 'timing' .?

I still don't know well. Without htx, the stream is created when the connection
is accepted and maintained till its end, so it may very well hold a reference
to the table entry even while the connection is idle waiting for a new request.
With HTX, it's like with H2, the stream only lives for the time it takes to
perform a request/response. I think that using barriers to get the output
after the request is sent but before the server starts to respond could
reveal the use=1 here. But apparently it's the barrier in the "haproxy-cli"
section of varnishtest that makes it crash so it might not be the easiest
thing to try for now. Maybe you can try placing the delay between the rxreq
and txresp statements in the server section and try to make sure your CLI
access happens in the middle :-/

Thanks,
Willy



Re: regtests - with option http-use-htx

2018-12-15 Thread PiBa-NL

Hi Willy,
Op 15-12-2018 om 17:06 schreef Willy Tarreau:

Hi Pieter,

On Sat, Dec 15, 2018 at 04:52:10PM +0100, PiBa-NL wrote:

Hi List, Willy,

Trying to run some existing regtests with added option: option http-use-htx

Using: HA-Proxy version 1.9-dev10-c11ec4a 2018/12/15

I get the below issues sofar:

 based on /reg-tests/connection/b0.vtc
Takes 8 seconds to pass, in a slightly modified manor 1.1 > 2.0 expectation
for syslog. This surely needs a closer look?
#    top  TEST ./htx-test/connection-b0.vtc passed (8.490)

It looks exactly like another issue we've found when a content-length
is missing but the close is not seen, which is the same in your case
with the first proxy returning the 503 error page by default. Christopher
told me he understands what's happening in this situation (at least for
the one we've met), I'm CCing him in case this report fuels this thoughts.

Ok thanks.



 based on /reg-tests/stick-table/b1.vtc
Difference here is the use=1 vs use=0 , maybe that is better, but then the
'old' expectation seems wrong, and the bug is the case without htx?

 h1    0.0 CLI recv|0x8026612c0: key=127.0.0.1 use=1 exp=0 gpt0=0 gpc0=0
gpc0_rate(1)=0 conn_rate(1)=1 http_req_cnt=1 http_req_rate(1)=1
http_err_cnt=0 http_err_rate(1)=0
 h1    0.0 CLI recv|
 h1    0.0 CLI expect failed ~ "table: http1, type: ip, size:1024,
used:(0|1\n0x[0-9a-f]*: key=127\.0\.0\.1 use=0 exp=[0-9]* gpt0=0 gpc0=0
gpc0_rate\(1\)=0 conn_rate\(1\)=1 http_req_cnt=1
http_req_rate\(1\)=1 http_err_cnt=0 http_err_rate\(1\)=0)\n$"

Hmmm here I think we're really hitting corner cases depending on whether
the tracked counters are released before or after the logs are emitted.
In the case of htx, the logs are emitted slightly later than before,
which may induce this. Quite honestly I'd be inclined to set use=[01]
here in the regex to cover the race condition that exists in both cases,
as there isn't any single good value. Christopher, are you also OK with
this ? I can do the patch if you're OK.
Its not about emitting logs, its querying the stats admin socket, and 
even with a added 'delay 2' before doing so the results seem to show the 
same difference with/without htx. I don't think its a matter of 'timing' .?


Regards,

PiBa-NL (Pieter)

**   c1    0.0 === expect resp.status == 503
 c1    0.0 EXPECT resp.status (503) == "503" match
***  c1    0.0 closing fd 7
**   c1    0.0 Ending
**   top   0.0 === delay 2
***  top   0.0 delaying 2 second(s)
**   top   2.1 === haproxy h1 -cli {
**   h1    2.1 CLI starting
**   h1    2.1 CLI waiting
***  h1    2.1 CLI connected fd 7 from ::1 26202 to ::1 26153
**   h1    2.1 === send "show table http1"
 h1    2.1 CLI send|show table http1
**   h1    2.1 === expect ~ "table: http1, type: ip, size:1024, 
used:(0|1\\n0x[...
***  h1    2.1 debug|0001:GLOBAL.accept(0005)=000b from [::1:26202] 
ALPN=

 h1    2.1 CLI connection normally closed
***  h1    2.1 CLI closing fd 7
***  h1    2.1 debug|0001:GLOBAL.srvcls[adfd:]
***  h1    2.1 debug|0001:GLOBAL.clicls[adfd:]
***  h1    2.1 debug|0001:GLOBAL.closed[adfd:]
 h1    2.1 CLI recv|# table: http1, type: ip, size:1024, used:1
 h1    2.1 CLI recv|0x8026612c0: key=127.0.0.1 use=1 exp=0 gpt0=0 
gpc0=0 gpc0_rate(1)=0 conn_rate(1)=1 http_req_cnt=1 
http_req_rate(1)=1 http_err_cnt=0 http_err_rate(1)=0

 h1    2.1 CLI recv|
 h1    2.1 CLI expect failed ~ "table: http1, type: ip, size:1024, 
used:(0|1\n0x[0-9a-f]*: key=127\.0\.0\.1 use=0 exp=[0-9]* gpt0=0 gpc0=0 
gpc0_rate\(1\)=0 conn_rate\(1\)=1 http_req_cnt=1 
http_req_rate\(1\)=1 http_err_cnt=0 http_err_rate\(1\)=0)\n$"





Re: regtests - with option http-use-htx

2018-12-15 Thread Willy Tarreau
Hi Pieter,

On Sat, Dec 15, 2018 at 04:52:10PM +0100, PiBa-NL wrote:
> Hi List, Willy,
> 
> Trying to run some existing regtests with added option: option http-use-htx
> 
> Using: HA-Proxy version 1.9-dev10-c11ec4a 2018/12/15
> 
> I get the below issues sofar:
> 
>  based on /reg-tests/connection/b0.vtc
> Takes 8 seconds to pass, in a slightly modified manor 1.1 > 2.0 expectation
> for syslog. This surely needs a closer look?
> #    top  TEST ./htx-test/connection-b0.vtc passed (8.490)

It looks exactly like another issue we've found when a content-length
is missing but the close is not seen, which is the same in your case
with the first proxy returning the 503 error page by default. Christopher
told me he understands what's happening in this situation (at least for
the one we've met), I'm CCing him in case this report fuels this thoughts.

>  based on /reg-tests/stick-table/b1.vtc
> Difference here is the use=1 vs use=0 , maybe that is better, but then the
> 'old' expectation seems wrong, and the bug is the case without htx?
> 
>  h1    0.0 CLI recv|0x8026612c0: key=127.0.0.1 use=1 exp=0 gpt0=0 gpc0=0
> gpc0_rate(1)=0 conn_rate(1)=1 http_req_cnt=1 http_req_rate(1)=1
> http_err_cnt=0 http_err_rate(1)=0
>  h1    0.0 CLI recv|
>  h1    0.0 CLI expect failed ~ "table: http1, type: ip, size:1024,
> used:(0|1\n0x[0-9a-f]*: key=127\.0\.0\.1 use=0 exp=[0-9]* gpt0=0 gpc0=0
> gpc0_rate\(1\)=0 conn_rate\(1\)=1 http_req_cnt=1
> http_req_rate\(1\)=1 http_err_cnt=0 http_err_rate\(1\)=0)\n$"

Hmmm here I think we're really hitting corner cases depending on whether
the tracked counters are released before or after the logs are emitted.
In the case of htx, the logs are emitted slightly later than before,
which may induce this. Quite honestly I'd be inclined to set use=[01]
here in the regex to cover the race condition that exists in both cases,
as there isn't any single good value. Christopher, are you also OK with
this ? I can do the patch if you're OK.

> Regards,
> 
> PiBa-NL (Pieter)
> 

Thanks,
Willy

> #commit b406b87
> # BUG/MEDIUM: connection: don't store recv() result into trash.data
> #
> # Cyril Bonté discovered that the proxy protocol randomly fails since
> # commit 843b7cb ("MEDIUM: chunks: make the chunk struct's fields match
> # the buffer struct"). This is because we used to store recv()'s return
> # code into trash.data which is now unsigned, so it never compares as
> # negative against 0. Let's clean this up and test the result itself
> # without storing it first.
> 
> varnishtest "PROXY protocol random failures"
> 
> feature ignore_unknown_macro
> 
> syslog Slog_1 -repeat 8 -level info {
> recv
> expect ~ "Connect from .* to ${h1_ssl_addr}:${h1_ssl_port}"
> recv
> expect ~ "ssl-offload-http/http .* \"POST /[1-8] HTTP/2\\.0\""
> } -start
> 
> haproxy h1 -conf {
> global
> nbproc 4
> nbthread 4
> tune.ssl.default-dh-param 2048
> stats bind-process 1
> log ${Slog_1_addr}:${Slog_1_port} len 2048 local0 debug err
> 
> defaults
> mode http
> timeout client 1s
> timeout server 1s
> timeout connect 1s
> log global
> 
> option http-use-htx
> 
> listen http
> bind-process 1
> bind unix@${tmpdir}/http.socket accept-proxy name ssl-offload-http
> option forwardfor
> 
> listen ssl-offload-http
> option httplog
> bind-process 2-4
> bind "fd@${ssl}" ssl crt ${testdir}/common.pem ssl no-sslv3 alpn 
> h2,http/1.1
> server http unix@${tmpdir}/http.socket send-proxy
> } -start
> 
> 
> shell {
> HOST=${h1_ssl_addr}
> if [ "$HOST" = "::1" ] ; then
> HOST="\[::1\]"
> fi
> for i in 1 2 3 4 5 6 7 8 ; do
> urls="$urls https://$HOST:${h1_ssl_port}/$i;
> done
> curl -i -k -d 'x=x' $urls & wait $!
> }
> 
> syslog Slog_1 -wait

> # commit 3e60b11
> # BUG/MEDIUM: stick-tables: Decrement ref_cnt in table_* converters
> #
> # When using table_* converters ref_cnt was incremented
> # and never decremented causing entries to not expire.
> #
> # The root cause appears to be that stktable_lookup_key()
> # was called within all sample_conv_table_* functions which was
> # incrementing ref_cnt and not decrementing after completion.
> #
> # Added stktable_release() to the end of each sample_conv_table_*
> # function and reworked the end logic to ensure that ref_cnt is
> # always decremented after use.
> #
> # This should be backported to 1.8
> 
> varnishtest "stick-tables: Test expirations when used with table_*"
> 
> # As some macros for haproxy are used in this file, this line is mandatory.
> feature ignore_unknown_macro
> 
> # Do nothing.
> server s1 {
> } -start
> 
> haproxy h1 -conf {
> # Configuration file of 'h1' haproxy instance.
> defaults
> mode   http
> timeout connect 5s
> timeout server  30s
> timeout client