[PATCH] DOC: Fix map table's format

[Ruoshan Huang]

Ahhh, I'm sorry to use attachment instead of git-send-email.
Anyway, the attached patch fix the table format, so the HTML version
document can be generated correctly.
Currently, the table here (
https://cbonte.github.io/haproxy-dconv/1.7/configuration.html#map) is
ill-formatted.


0001-DOC-Fix-map-table-s-format.patch
Description: Binary data

Re: counters for specific http status code

[Ruoshan Huang]

>
>
> Yes you're right. For me this one fixes it (both with http-request and
> multiple http-response), is that OK for you ?
>
>
Yes, looks good to me.

-- 
Good day!
ruoshan

Re: counters for specific http status code

[Ruoshan Huang]

I'm afraid I have to duplicate some logic here, like:
```
if((unsigned)(txn->status - 400) < 100) {
ptr = stktable_data_ptr(t, ts,
STKTABLE_DT_HTTP_ERR_CNT);
if (ptr)
stktable_data_cast(ptr, http_err_cnt)++;

ptr = stktable_data_ptr(t, ts,
STKTABLE_DT_HTTP_ERR_RATE);
if (ptr)
update_freq_ctr_period(&stktable_data_cast(ptr,
http_err_rate),

 t->data_arg[STKTABLE_DT_HTTP_ERR_RATE].u, 1);
}
```

On Tue, Jul 26, 2016 at 8:44 PM, Ruoshan Huang 
wrote:

> Ah, I just find a problem in this snip
>
> ```
> +   if ((unsigned)(txn->status - 400)
> < 100)
> +   stream_inc_http_err_ctr(s);
> ```
> calling `stream_inc_http_err_ctr` may cause the http_err_cnt be increased
> twice for other stick counter tracked by `http-request track-sc`. for
> example:
>
> ```
> frontend fe
> bind *:7001
> stick-table type ip size 100 expire 10m store http_req_cnt,http_err_cnt
> http-request track-sc1 src
> http-response track-sc2 status table dummy
> default_backend be
>
> backend be
> server b1 127.0.0.1:8000
>
> backend dummy
> stick-table type integer size 100 expire 10m store
> http_req_cnt,http_err_cnt
> ```
> the `http_err_cnt` in table `fe` will be increased twice for every 4xx
> response.
>
> we should only increase the err counter for the current stick counter
> entry.
>
> On Tue, Jul 26, 2016 at 8:34 PM, Willy Tarreau  wrote:
>
>> On Tue, Jul 26, 2016 at 06:24:50PM +0800, Ruoshan Huang wrote:
>> > >
>> > > If you're fine with this, I'll simply merge them with the change
>> above,
>> > > it's clean enough, no need to respin. Please just confirm that it's
>> fine
>> > > for you as well.
>> > >
>> > >
>> > Yes, please ship it.
>> > Thank you so much.
>>
>> OK now merged. I tested this config on it :
>>
>> http-response track-sc0 status
>> stick-table type integer size 200k store http_req_cnt,http_err_cnt
>>
>> and it works pretty fine :
>>
>> $ echo "show table l" | socat - /tmp/sock1
>> # table: l, type: integer, size:204800, used:3
>> 0x7ef7b0: key=302 use=0 exp=0 http_req_cnt=1 http_err_cnt=0
>> 0x7ef718: key=404 use=0 exp=0 http_req_cnt=1 http_err_cnt=1
>> 0x7ef070: key=200 use=0 exp=0 http_req_cnt=2 http_err_cnt=0
>>
>> That's cool :-)
>>
>> Thanks,
>> Willy
>>
>
>
>
> --
> Good day!
> ruoshan
>



-- 
Good day!
ruoshan

Re: counters for specific http status code

[Ruoshan Huang]

Ah, I just find a problem in this snip

```
+   if ((unsigned)(txn->status - 400) <
100)
+   stream_inc_http_err_ctr(s);
```
calling `stream_inc_http_err_ctr` may cause the http_err_cnt be increased
twice for other stick counter tracked by `http-request track-sc`. for
example:

```
frontend fe
bind *:7001
stick-table type ip size 100 expire 10m store http_req_cnt,http_err_cnt
http-request track-sc1 src
http-response track-sc2 status table dummy
default_backend be

backend be
server b1 127.0.0.1:8000

backend dummy
stick-table type integer size 100 expire 10m store
http_req_cnt,http_err_cnt
```
the `http_err_cnt` in table `fe` will be increased twice for every 4xx
response.

we should only increase the err counter for the current stick counter entry.

On Tue, Jul 26, 2016 at 8:34 PM, Willy Tarreau  wrote:

> On Tue, Jul 26, 2016 at 06:24:50PM +0800, Ruoshan Huang wrote:
> > >
> > > If you're fine with this, I'll simply merge them with the change above,
> > > it's clean enough, no need to respin. Please just confirm that it's
> fine
> > > for you as well.
> > >
> > >
> > Yes, please ship it.
> > Thank you so much.
>
> OK now merged. I tested this config on it :
>
> http-response track-sc0 status
> stick-table type integer size 200k store http_req_cnt,http_err_cnt
>
> and it works pretty fine :
>
> $ echo "show table l" | socat - /tmp/sock1
> # table: l, type: integer, size:204800, used:3
> 0x7ef7b0: key=302 use=0 exp=0 http_req_cnt=1 http_err_cnt=0
> 0x7ef718: key=404 use=0 exp=0 http_req_cnt=1 http_err_cnt=1
> 0x7ef070: key=200 use=0 exp=0 http_req_cnt=2 http_err_cnt=0
>
> That's cool :-)
>
> Thanks,
> Willy
>



-- 
Good day!
ruoshan

Re: counters for specific http status code

[Ruoshan Huang]

>
> If you're fine with this, I'll simply merge them with the change above,
> it's clean enough, no need to respin. Please just confirm that it's fine
> for you as well.
>
>
Yes, please ship it.
Thank you so much.

--
Good day!
ruoshan

Re: counters for specific http status code

[Ruoshan Huang]

hi Willy,    please check this thread again when you are free. thanks

--
ruoshan
from Outlook mobile




On Thu, Jul 21, 2016 at 3:30 AM +0800, "Willy Tarreau"  wrote:










Hi Ruoshan,

On Thu, Jul 14, 2016 at 03:24:42PM +0800, Ruoshan Huang wrote:
> hi,
> here is my (final?) patch for implementing `http-response track-sc*` 
> directive. mainly I have:
> - duplicate config parsing (`parse_http_res_cond`) and validation 
> (`check_config_validity`) code for track-sc
> - add ACT_ACTION_TRK_SC* case in `http_res_get_intercept_rule` to do the 
> tracking
> - rename http_req_trk_idx to http_trk_idx
> - doc of course
> 
>and the  smp expr for this directive requires smp with capability of 
> `SMP_VAL_FE/BE_HRS_HDR`,
> I try to explain this in the document, but the `fetch_cap` is very 
> complicated, hope I didn't fail explaining it :)
> 
>please review these patchs when you're avaliable, Thanks.

I'm leaving your mail marked "unread" so that I avoid to miss it. If
you don't get any feedback by the end of next week, please ping again.

Thanks,
Willy

Re: counters for specific http status code

[Ruoshan Huang]

hi,
here is my (final?) patch for implementing `http-response track-sc*` 
directive. mainly I have:
- duplicate config parsing (`parse_http_res_cond`) and validation 
(`check_config_validity`) code for track-sc
- add ACT_ACTION_TRK_SC* case in `http_res_get_intercept_rule` to do the 
tracking
- rename http_req_trk_idx to http_trk_idx
- doc of course

   and the  smp expr for this directive requires smp with capability of 
`SMP_VAL_FE/BE_HRS_HDR`,
I try to explain this in the document, but the `fetch_cap` is very complicated, 
hope I didn't fail explaining it :)

   please review these patchs when you're avaliable, Thanks.



0001-implementing-http-response-track-sc-directive.patch
Description: Binary data


0002-add-doc-for-http-response-track-sc.patch
Description: Binary data

--
Good day!
ruoshan

Re: counters for specific http status code

[Ruoshan Huang]

On Jul 12, 2016, at 12:42 PM, Willy Tarreau  wrote:Please take a look at how track-sc are added  to http-request, look for"ACT_ACTION_TRK_SC0" in proto_http.c, you'll find your way through it,and see if you can duplicate this to the response.I just baked some draft patchs. and get some questions:1. I didn't follow the early code cleanup, and now in v1.6 branch, there is a struct list called `http_res_actions`, should new actions be put in that list instead? the refactoring history spawned many commits, I couldn't figure out the orginal intention.2. what's the purpose of there two macro: `STKCTR_TRACK_BACKEND` and `STKCTR_TRACK_CONTENT`, couldn't find too much comment.3. it feels a little wired to me to store the stick counter data type like `http_req_rate` or `conn_rate` in a http response phase.

0001-add-httprsp-track-sc.patch
Description: Binary data


0002-rename-http_req_trk_idx-to-http_trk_idx.patch
Description: Binary data

--Good day!ruoshan

Re: counters for specific http status code

[Ruoshan Huang]

> On Jul 12, 2016, at 12:42 PM, Willy Tarreau  wrote:
> 
> Please take a look at how track-sc are added  to http-request, look for
> "ACT_ACTION_TRK_SC0" in proto_http.c, you'll find your way through it,
> and see if you can duplicate this to the response. There should be a few
> tricks such as indicating that you want data present in the response
> instead of the request, but nothing terrible. I think you shouldn't have
> too many issues adding support for this. Please note however that by
> definition it will not count haproxy's own status codes but only the
> ones it is forwarding. But in general that shouldn't be an issue as
> when you want such details you're more interested in the status codes
> generated by the application than the ones generated by haproxy.


Will do! Thanks

--
Good day!
ruoshan

Re: counters for specific http status code

[Ruoshan Huang]

hi,

> On Jul 12, 2016, at 12:05 PM, Willy Tarreau  wrote:
> 
> Hi Ruoshan,
> 
> On Tue, Jul 05, 2016 at 12:28:43PM +0800, Ruoshan Huang wrote:
>> hi,
>>I use the hrsp4xx/hrsp5xx a lot to do timeseries metric collecting,
>>sometimes the these counters lack details. I'm wondering what's the
>>badside of no collecting all the HTTP status (just an array of 500
>>length? I know there're many empty slot in it).
> 
> What I'm seeing is that it will consume 4 more kB of memory in each
> proxy. That can be a bit problematic for people who use a *lot* of
> backends. The largest configs I've been aware were 30 backends
> (yes I know that sounds insane). This would add 1.2 GB of RAM just
> to add these extra counters. We could imagine dynamically storing
> them into a tree but it would consume so much more per individual
> entry that it would not be worth it.

Thank you so much for elaborating in such detail !

Indeed I only care about 20 status code or so, like 400, 401, 403 (I have been 
bitten many times by treating those codes as 404 :( ), and 50x also helps a lot 
in our alerting system as a first method for diagnosing abnormal things. By and 
large, the "big" array does waste a lot of memory (I know), but that's the fast 
way I try to make a demo.

> 
>>Currently I have to do the accounting on the log file. but on a high load
>>machine, it cost a lot to processing the log itself.
> 
> Well, on my local machine, halog takes only 0.98 second to process a 2.3 GB
> file and give me the status distribution (8.4 million lines). That's 2.4 GB
> per second or 8.6 million lines per second. This is not something I would
> consider as a high load, because if you rotate your log files past 2 GB,
> you'd eat less than 1 second of CPU for each analysis. It's probably less
> than what can be lost per hour due to cache misses when adding 4kB per
> proxy to a large config in fact :-/

havn't used `halog` for parsing, will try it. but I prefer collecting metrics 
remotely, there are many hosts and stat sock can dump the stick table (stick 
table is realy amazing, thank you for developing this!)

> 
>> There're ways like
>>logstash or log to remote machine. but do the accounting on HA seems to
>>be a very light approach.
>>I've a draft patch for this feature, just adding a stats socket command
>>like `show httprsp[backend]`. Wish to get some
>>idea on this. Thanks
> 
> I'm not opposed to trying to store a bit more stats, but as you saw we'd
> be eating a lot of memory to store a lot of holes. Could you please do me
> a favor, and count the number of different status codes you're seeing on
> your side ? There's a compact variant of the ebtree which saves two pointers
> and which would require only 2 pointers, a key and a value per node, hence
> around 26 bytes, or 18 or even 14 with relative addressing if we limit the
> number of different statuses per proxy. Maybe this combined with dynamic
> allocation to move that part out of the struct proxy would make sense
> because 1) it would eat much less memory per proxy for small number of
> statuses (eg: break-even around 150 different statuses) and would not
> eat memory for backends with little or no traffic. It would also allow
> us to remove the rsp[6] array since we would be able to compute these
> values by walking over the tree.
> 

At first I was thinking whether we could track the response status in stick 
table, then it may be neat. but currently there isn't `http-response track-sc?` 
directive. can it?

Using a dynamic ebtree will eventually recreating a tracking table or something 
like the stick table, so same question here: is it possible do the stick 
counter tracking in response phase, so more things can be tracked.

--
Good day!
ruoshan

counters for specific http status code

[Ruoshan Huang]

hi,
I use the hrsp4xx/hrsp5xx a lot to do timeseries metric collecting, 
sometimes the these counters lack details. I'm wondering what's the badside of 
no collecting all the HTTP status (just an array of 500 length? I know there're 
many empty slot in it).
Currently I have to do the accounting on the log file. but on a high load 
machine, it cost a lot to processing the log itself. There're ways like 
logstash or log to remote machine. but do the accounting on HA seems to be a 
very light approach.
I've a draft patch for this feature, just adding a stats socket command 
like `show httprsp[backend]`. Wish to get some idea 
on this. Thanks



0001-supporting-dumping-http-response-status-code.patch
Description: Binary data


--
Good day!
ruoshan

Re: HTML documentation : work in progress

[Ruoshan Huang]

Thank you!
Having using these html for a long time. I also make a docset for the Dash app, 
if you're a Mac user, it may be handy :). To use it, just search the `User 
Contributed` in preference of the app. All keywords are indexed

> On Jun 28, 2016, at 5:40 AM, Cyril Bonté  wrote:
> 
> Hi all,
> 
> It's been monthes since haproxy has introduced new documentation files in 1.6 
> and 1.7-dev (ie. intro.txt, management.txt, ...). Until now, I hardly found 
> time to include them in the HTML documentation. It's time to seriously work 
> on this issue !
> 
> There is quite a lot of things to do before I can say everything is ready, 
> but let's go ! This means that things will break for some days. At least, 
> currently I've disabled the job that regenerates the documentations 
> automatically until things become more stable again (New documentation 
> commits won't appear).
> 
> I'm also thinking of reorganizing the documentation with one directory per 
> major version (1.4, 1.5, 1.6, 1.7).
> 
> Tasks in the highest priorities :
> - allow to navigate between files
> - search keywords in all files
> - fix rendering issues (I know there are several parts that are not correctly 
> parsed)
> 
> As an early preview those files are available here :
> - haproxy 1.4
> http://cbonte.github.io/haproxy-dconv/1.4/configuration.html
> 
> - haproxy 1.5
> http://cbonte.github.io/haproxy-dconv/1.5/configuration.html
> 
> - haproxy 1.6
> http://cbonte.github.io/haproxy-dconv/1.6/intro.html
> http://cbonte.github.io/haproxy-dconv/1.6/configuration.html
> http://cbonte.github.io/haproxy-dconv/1.6/management.html
> 
> - haproxy 1.7
> http://cbonte.github.io/haproxy-dconv/1.7/intro.html
> http://cbonte.github.io/haproxy-dconv/1.7/configuration.html
> http://cbonte.github.io/haproxy-dconv/1.7/management.html
> 
> -- 
> Cyril Bonté
> 

--
Good day!
ruoshan

Re: [PATCH] BUG/MINOR: fix http-response set-log-level parsing error

[Ruoshan Huang]

is this post never make it to the list?
I keep receiving a spam reply telling me about delivery failure :(

anyway, please consider merging this patch.

> On Jun 15, 2016, at 10:16 PM, Ruoshan Huang  wrote:
> 
> hi,
>`http-response set-log-level` doesn't work, as the config parsing always 
> set the log level to -1.
> 
> <0001-BUG-MINOR-fix-http-response-set-log-level-parsing-er.patch>
> 
> --
> Good day!
> ruoshan
> 

--
Good day!
ruoshan

[PATCH] BUG/MINOR: fix http-response set-log-level parsing error

[Ruoshan Huang]

hi,
`http-response set-log-level` doesn't work, as the config parsing always 
set the log level to -1.



0001-BUG-MINOR-fix-http-response-set-log-level-parsing-er.patch
Description: Binary data


--
Good day!
ruoshan

Re: sc-inc-gpc0() doesn't update the gpc0_rate

[Ruoshan Huang]

Great ! Thank you

> On Jan 25, 2016, at 9:59 PM, Willy Tarreau  wrote:
> 
> Hi Ruoshan,
> 
> On Wed, Jan 20, 2016 at 03:41:54PM +0800, Ruoshan Huang wrote:
>> hi,
>>HAProxy (1.6.3) doesn???t update the gpc0_rate accordingly when I do 
>> things like:
>> 
>> ```
>>stick-table type ip size 1k expire 30m store gpc0_rate(10s),gpc0
>>tcp-request inspect-delay 3s
>>tcp-request connection track-sc0 src
>>tcp-request connection sc-inc-gpc0(0)
>> ```
>> 
>> the gpc0 did get increased, but the gpc0_rate was NOT updated. the function 
>> `action_inc_gpc0` just do `gpc0++` and no more.
>> 
>>   I could use the `acl increase_gpc sc_inc_gpc0(0) gt 0` instead, as the 
>> function `smp_fetch_sc_inc_gpc0` is called (so the gpc0_rate is updated).
>> 
>>   Is this a bug?
> 
> I've now fixed it in mainline and the fix is scheduled for a backport to 1.6
> as well. Please note that the table wasn't touched so the entry may even 
> expire
> and will not be synchronized with other peers either. set-gpt0 had the same 
> bug.
> 
> Thanks for reporting it,
> Willy

--
Good day!
ruoshan

sc-inc-gpc0() doesn't update the gpc0_rate

[Ruoshan Huang]

hi,
HAProxy (1.6.3) doesn’t update the gpc0_rate accordingly when I do things 
like:

```
stick-table type ip size 1k expire 30m store gpc0_rate(10s),gpc0
tcp-request inspect-delay 3s
tcp-request connection track-sc0 src
tcp-request connection sc-inc-gpc0(0)
```

the gpc0 did get increased, but the gpc0_rate was NOT updated. the function 
`action_inc_gpc0` just do `gpc0++` and no more.

   I could use the `acl increase_gpc sc_inc_gpc0(0) gt 0` instead, as the 
function `smp_fetch_sc_inc_gpc0` is called (so the gpc0_rate is updated).

   Is this a bug?

--
Good day!
ruoshan

DOC: Session 9 is gone?

[Ruoshan Huang]

I didn’t notice before, the "Session 9” in configuration.txt is gone.

--
Good day!
ruoshan

Re: what's the difference between rspdel and http-response del-header

[Ruoshan Huang]

fix my patch formation :)



doc.patch
Description: Binary data


--
Good day!
ruoshan

Re: what's the difference between rspdel and http-response del-header

[Ruoshan Huang]

Here is my patch. I will try to update the whole `Session 6: HTTP header 
manipulation` in my next patch :)



doc-header-manipulation-directives.patch
Description: Binary data


--
Good day!
ruoshan

Re: what's the difference between rspdel and http-response del-header

[Ruoshan Huang]

> On Dec 8, 2015, at 3:26 AM, Willy Tarreau  wrote:
> 
> Would you be willing to propose your first patch to address
> this ? reqadd, reqdel, reqdeny, reqallow, rspadd, rspdel, rspdeny, rspallow
> are directly concerned.


Yes, I’d love to update the doc.

There is one problem here:
the `reqdel reqidel` works with regular exp, but `http-response del-header` 
only works with plain text. so those old directives are not as “deprecated” as 
they are :)

Also, the `rspadd rspdel` runs after `http-response` so things like below would 
not works as expected:
```
rspadd XX:\ default
http-response set-header XX other if COND
```
the `XX: default` hdr will always in response, can I have this behaviour stated 
in the doc too?

--
Good day!
ruoshan

Re: what's the difference between rspdel and http-response del-header

[Ruoshan Huang]

> On Dec 4, 2015, at 2:41 AM, Bryan Talbot  wrote:
> 
> rspdel is older and remains for backwards compatibility.

if so, maybe the document should flag those directives `deprecated` :)

Thank you for explaining.

--
Good day!
ruoshan

what's the difference between rspdel and http-response del-header

[Ruoshan Huang]

hi,
I’m a confused about the difference between `rspdel` and `http-response 
del-header`. if all I want is to delete a hdr of plain text instead of regular 
expression, does `http-response del-header` perform faster? under what 
circumstance should I use `rspxxx` directives instead?
Thanks.

--
Good day!
ruoshan

Re: Execution order of some directives

[Ruoshan Huang]

Oops, It’s "`reqadd` must come before the `http-request add-header`". 

> On Sep 29, 2015, at 5:38 PM, Ruoshan Huang  wrote:
> 
>   1. `reqadd` VS. `http-request add-header`. I can see the warning in the log 
> about the reqadd must be added before http-request, but it’s not 
> documented(or I miss it).

--
Good day!
ruoshan

Execution order of some directives

[Ruoshan Huang]

hi,
After reading the config manual, I have some questions about the 
directives’ executing order:

   1. `reqadd` VS. `http-request add-header`. I can see the warning in the log 
about the reqadd must be added before http-request, but it’s not documented(or 
I miss it).
   2. `http-request add-header` VS. `capture request header`. I want to add 
some headers in the log, but failed to capture the manipulated header.


Coming from NGINX, I’m used to the PHASES model in nginx. say the `set` is 
promised to execute before `echo`, things like that. But in HAProxy, I 
sometimes got confused in which directives will execute first and which 
follows. and I can’t spot the mistake until I’m given a warning in the log. How 
can I find more info to figure these out.

Thank you.

--
Good day!
ruoshan

Re: can I get the uptime per server in csv stats

[Ruoshan Huang]

Thank you.
I was seeking the document for string `uptime` and `time`, but nothing related 
found. how silly :)

> On Jul 17, 2015, at 2:35 PM, Pavlos Parissis  
> wrote:
> 
> 
> On 17/07/2015 06:02 πμ, Ruoshan Huang wrote:
>> hi,
>>I found that the html stats page has a column of status which comes with 
>> the uptime of a server or backend,
>> but in the csv stats I couldn’t find the uptime accordingly.
>>Can I get the uptime of servers without parsing the html? Thanks.
>> 
>> --
>> Good day!
>> ruoshan
>> 
>> 
> 
> I believe it is the lastchg field name,
> 23. lastchg [..BS]: number of seconds since the last UP<->DOWN transition
> 
> sudo haproxytool server -m lastchg node1 --backend=b1
> # backendname servername
> b1 node1 53856
> 
> Cheers,
> Pavlos
> 

--
Good day!
ruoshan

can I get the uptime per server in csv stats

[Ruoshan Huang]

hi,
I found that the html stats page has a column of status which comes with 
the uptime of a server or backend,
but in the csv stats I couldn’t find the uptime accordingly.
Can I get the uptime of servers without parsing the html? Thanks.

--
Good day!
ruoshan

Re: gpc0 got increased twice when used with WAIT_END

[Ruoshan Huang]

Oops, forgot to provide the version. it’s `HA-Proxy version 1.5.11 2015/01/31`

> On Apr 17, 2015, at 00:41, Ruoshan Huang  wrote:
> 
> hi,
>  I have this demo configuration below. I try to reject the request when 
> http_req_rate is too high,
> and re-accept the request from the client after it’s rejected twice. But this 
> configuration doesn’t work that way out,
> it just re-accept the request after client was reject once. and I find out 
> the gpc0 was increased twice when
> the WAIT_END was evaluated. Is this behavior normal? Please help me 
> understand it.
> 
> This is my configs:
> 
> ```
> global
> stats socket ipv4@127.0.0.1 <mailto:ipv4@127.0.0.1>: level admin mode 
> 666
> stats timeout 8m
> chroot  /usr/share/haproxy
> pidfile /run/haproxy.pid
> userhaproxy
> 
> 
> defaults
> modehttp
> option  forwardfor
> option  redispatch
> retries 3
> timeout http-request10s
> timeout queue   1m
> timeout connect 10s
> timeout client  1m
> timeout server  1m
> timeout http-keep-alive 10s
> timeout check   10s
> maxconn 3000
> 
> 
> frontend stats
> bind *:7070
> stats uri /
> 
> 
> frontend  main
> bind *:7000
> stick-table type ip size 100m expire 30m store 
> http_req_rate(10s),conn_cur,gpc0
> tcp-request inspect-delay 30s  #make it long enough to debug
> tcp-request content track-sc1 src
> 
> # rate limiting
> # # criterions
> acl inc_gpc sc1_inc_gpc0() gt 0
> acl clr_gpc sc1_clr_gpc0() ge 0
> acl is_sensitive_url path /
> acl is_abused sc1_http_req_rate gt 1
> acl is_conn_normal sc1_conn_cur() lt 3
> acl already_abused sc1_get_gpc0() gt 0
> acl clr_abused sc1_get_gpc0() gt 2
> # # actions
> tcp-request content accept if is_conn_normal clr_abused clr_gpc   #set 
> the gpc0 to 0 after it has been rejected twice
> tcp-request content reject if is_sensitive_url already_abused inc_gpc 
> WAIT_END  ###HERE is the problem line I have
> http-request add-header X-Req-Rate %[sc1_http_req_rate()]/10sec if 
> is_sensitive_url is_abused inc_gpc
> 
> default_backend ngx
> 
> 
> backend ngx
> server ngx01 127.0.0.1:8080 maxconn 3
> ```
> 
> --
> Good day!
> ruoshan
> 

--
Good day!
ruoshan

gpc0 got increased twice when used with WAIT_END

[Ruoshan Huang]

hi,
 I have this demo configuration below. I try to reject the request when 
http_req_rate is too high,
and re-accept the request from the client after it’s rejected twice. But this 
configuration doesn’t work that way out,
it just re-accept the request after client was reject once. and I find out the 
gpc0 was increased twice when
the WAIT_END was evaluated. Is this behavior normal? Please help me understand 
it.

This is my configs:

```
global
stats socket ipv4@127.0.0.1: level admin mode 666
stats timeout 8m
chroot  /usr/share/haproxy
pidfile /run/haproxy.pid
userhaproxy


defaults
modehttp
option  forwardfor
option  redispatch
retries 3
timeout http-request10s
timeout queue   1m
timeout connect 10s
timeout client  1m
timeout server  1m
timeout http-keep-alive 10s
timeout check   10s
maxconn 3000


frontend stats
bind *:7070
stats uri /


frontend  main
bind *:7000
stick-table type ip size 100m expire 30m store 
http_req_rate(10s),conn_cur,gpc0
tcp-request inspect-delay 30s  #make it long enough to debug
tcp-request content track-sc1 src

# rate limiting
# # criterions
acl inc_gpc sc1_inc_gpc0() gt 0
acl clr_gpc sc1_clr_gpc0() ge 0
acl is_sensitive_url path /
acl is_abused sc1_http_req_rate gt 1
acl is_conn_normal sc1_conn_cur() lt 3
acl already_abused sc1_get_gpc0() gt 0
acl clr_abused sc1_get_gpc0() gt 2
# # actions
tcp-request content accept if is_conn_normal clr_abused clr_gpc   #set the 
gpc0 to 0 after it has been rejected twice
tcp-request content reject if is_sensitive_url already_abused inc_gpc 
WAIT_END  ###HERE is the problem line I have
http-request add-header X-Req-Rate %[sc1_http_req_rate()]/10sec if 
is_sensitive_url is_abused inc_gpc

default_backend ngx


backend ngx
server ngx01 127.0.0.1:8080 maxconn 3
```

--
Good day!
ruoshan