[PATCH] DOC: Fix map table's format

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-

Re: counters for specific http status code

> > > 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

} ``` 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)

Re: counters for specific http status code

t 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&

Re: counters for specific http status code

> > 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

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 (f

Re: counters for specific http status code

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 -

Re: counters for specific http status code

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

Re: counters for specific http status code

> 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 in

Re: counters for specific http status code

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

counters for specific http status code

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 accoun

Re: HTML documentation : work in progress

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, >

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

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 conf

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

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

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: >>

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

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 ge

DOC: Session 9 is gone?

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

fix my patch formation :) doc.patch Description: Binary data -- Good day! ruoshan

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

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

> 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 re

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

> 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

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.

Re: Execution order of some directives

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

Execution order of some directives

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

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

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 h

can I get the uptime per server in csv stats

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

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 fro

gpc0 got increased twice when used with WAIT_END

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