Hi Ruoshan, On Wed, Jul 13, 2016 at 07:29:57PM +0800, Ruoshan Huang wrote: > > > On Jul 12, 2016, at 12:42 PM, Willy Tarreau <[email protected]> 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.
Ah I forgot about this. If you find how to do it, yes please. But I know we've not converted the track-sc to this yet, and I guess you won't be able to use this for now due to the fact that this list contains plain words only and that here we have optional arguments and even a configurable number of counters. So most likely you'll have to do as is done for the other track-sc actions and add dedicated code. The intent of the refactoring was to be able to register a same action for use in multiple places. We used to have too much duplication and there was a strong temptation to only implement certain actions at certain places, which was counter-productive. > 2. what's the purpose of there two macro: `STKCTR_TRACK_BACKEND` and > `STKCTR_TRACK_CONTENT`, couldn't find too much comment. - the first one indicates that a tracking pointer was set from the backend and thus that when a keep-alive request goes to another backend, the track must cease. - the second one indicates that the tracking pointer was set in a content-aware rule (tcp-request content or http-request) and that the tracking has to be performed in the stream and not in the session, and will cease for a new keep-alive request over the same connection. In your case you'll set at least STKCTR_TRACK_CONTENT, and you'll add STKCTR_TRACK_BACKEND when you find that strm->be != sess->fe. > 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. I understand your feeling, it looks strange at first. The terms are maybe not the best ones but they're the ones we have. Here it will correspond to a number of request having triggerred your rule for example. If you see them as L4 events or L7 events, it may sound more natural. Regards, Willy
