Re: Keeping conns alive on server side irrespective of client side conns

[Baptiste]

On Wed, Sep 23, 2015 at 3:15 PM, Pradeep Jindal  wrote:
> Hi,
>
> Does anyone know of a way to keep connections alive on the server side
> irrespective of whether clients close them or not?
>
> HAProxy keeps a connection alive to the server only if the corresponding
> client side connection is still up. So, essentially server side keepalive is
> only supported if client side keepalive is also there otherwise, haproxy
> closes the server side connection as soon as the client closes it.
>
> It'll be useful, in HTTP mode, to keep server side connections alive so that
> those can be used a firehouse pipes to the backend servers and requests can
> be round-robin over those kept alive connections accordingly.
>
> - Pradeep Jindal


Hi Pradeep,

http-reuse implemented might help a bit your case:
http://cbonte.github.io/haproxy-dconv/snapshot/configuration-1.6.html#http-reuse

That said, what you want might be a real connection pool, which
doesn't exist yet in HAProxy.

Baptiste

Re: Segfault on basic auth?

[Phillip Decker]

Ahh, yes okay I saw the thread but didn't imagine it was related.

I'll be able to test the newest tomorrow, and I'll close the loop here.

Thanks for all you do,
Phillip

On Wed, Sep 23, 2015 at 3:40 AM, Willy Tarreau  wrote:

> Hi Phillip,
>
> On Wed, Sep 23, 2015 at 12:59:05PM +0930, Phillip Decker wrote:
> > Hi guys,
> >
> > Not to pile on, but when running with 1.6-dev4, I've noticed a segfault
> > that doesn't happen if you substitute 1.5.9 back in.  I can post more
> here
> > later in the day, but I have a meeting to run to shortly-
>
> (...)
>
> I introduced a bug with the http-reuse which causes statuses 401 and 407
> on http-server-close connections to dereference a NULL. It was fixed in
> dev5. I'm pretty sure that's what you're seeing. Just update do dev5 or
> better, latest snapshot, to confirm you don't see it anymore.
>
> thanks,
> Willy
>
>

SSDP most used DDOS vector

[Emeric Brun]

Hi All,

I want to share because i just found out this:

Since the beginning of the year, SSDP(upnp) is the most used protocol for 
amplified DDOS attacks. Today, it appears 2x to 3x more used than DNS or NTP.

You could find a lot of articles related while searching SSDP+DDOS on google. 
The main source is Akamai.

http://www.networkworld.com/article/2925152/microsoft-subnet/akamai-report-ddos-attacks-doubled-in-q1-2015-ssdp-top-attack-vector.html


R,
Emeric

Re: Keeping conns alive on server side irrespective of client side conns

[Pradeep Jindal]

http-reuse won't serve the purpose here as it needs sessions to persist
from client side for being able to reuse them for other sessions' requests.

You are right a real connection pool is what I am looking for.
On Sep 23, 2015 6:50 PM, "Baptiste"  wrote:

> On Wed, Sep 23, 2015 at 3:15 PM, Pradeep Jindal 
> wrote:
> > Hi,
> >
> > Does anyone know of a way to keep connections alive on the server side
> > irrespective of whether clients close them or not?
> >
> > HAProxy keeps a connection alive to the server only if the corresponding
> > client side connection is still up. So, essentially server side
> keepalive is
> > only supported if client side keepalive is also there otherwise, haproxy
> > closes the server side connection as soon as the client closes it.
> >
> > It'll be useful, in HTTP mode, to keep server side connections alive so
> that
> > those can be used a firehouse pipes to the backend servers and requests
> can
> > be round-robin over those kept alive connections accordingly.
> >
> > - Pradeep Jindal
>
>
> Hi Pradeep,
>
> http-reuse implemented might help a bit your case:
>
> http://cbonte.github.io/haproxy-dconv/snapshot/configuration-1.6.html#http-reuse
>
> That said, what you want might be a real connection pool, which
> doesn't exist yet in HAProxy.
>
> Baptiste
>

galvanized welded mesh

[Anna]

We are the manufacturer of welded wire mesh.

1. for construction and building material  :

to be used for coal mine tunnel protection ,tunnel liner ,house floor , 
roof, reinforce the concrete and brick for the wall,bridge,road,for fence

  1)Weded wire mesh panel fence: to fence the road,house,railway,runway and so 
on

  2)Brick block reinforcement ladder mesh/truss
  
  3)Underground coal mine supporting net 

  4)Stucco welded wire mesh:Also called stucco welded wire lath, estazolam 
plate net,external wall insulation welded wire mesh.
  
 A new wall building material,can 
instead of the brick to be the load bearing wall,floor,balcony.
  
  5)Floor warming mesh, radiant floor heating mesh

  6)Gabion mesh

2. other usage

  1)Corn welded wire mesh

  2)Seeding bed mesh:also called flower breeding growing mesh,greenhouse 
seeding bed net


If you import,then welcome your inquiry. 

-
 
Best Regards

Anna

Shenzhou Sirun Wire Mesh Products Co. Ltd.
　　
Mobile: 15333187692   Tel: 0318-3608999 Fax: 0318-3601999

Skype:weldedwirenetting

Address: Shenzhou City Song Jia Ying Industrial Park,Hengshui,Hebei,China

www.chinaweldedmeshfence.comwww.sirunwangye.com

Re: Keeping conns alive on server side irrespective of client side conns

[Willy Tarreau]

On Wed, Sep 23, 2015 at 10:37:28PM +0530, Pradeep Jindal wrote:
> I know, but that's totally dependant on what kind of clients one has online
> and that's nondeterministic, but still can help.

Yes. The pool is on my papers only. I wanted to do it just after the reuse,
but I noticed a few nits that would need more time and this happened just
when we started to debug massive amounts of crap, so this definitely got
postponed.

Willy

Re: HAProxy/Lua survey about lua configuration form

[Thierry FOURNIER]

On Wed, 23 Sep 2015 09:37:41 +0200
Willy Tarreau  wrote:

> On Tue, Sep 22, 2015 at 10:18:10PM -0400, Michael Ezzell wrote:
> > I don't see a significant problem, if there are benefits to be gained.
> > 
> > I assume part of the motivation is to prevent inadvertently calling an
> > inappropriate function as an action, to perhaps to allow earlier validation
> > of the configuration of actions referencing Lua functions, and to separate
> > the namespaces of Lua functions and HAProxy Lua actions.
> 
> I'm seeing the same benefit. In fact I even *thought* that actions were
> registered like fetch/convs. But the current state of affairs now scares
> me for the future because indeed we don't want to call random functions
> by accident. Also, I don't know if some functions are shipped with Lua,
> but it could be painful if a new version of Lua brings new functions
> which collide with ones that people use in their configs. With a
> registration mechanism this cannot happen at all, so it's much safer.
> 
> It will also allow to use a wider character set in action names (eg: '-'
> or '.' that we use in the core config language). So all in all I think it's
> a good idea that's worth being done *before* the actual release otherwise
> we could regret it later.
> 
> Thierry, what's the impact of such a change (in terms of complexity, amount
> of code changed, risks of regressions, etc) ? I've found the issues I've been
> debugging since last week-end, they're fixed on paper now, I just need to fix
> the code and I'm thinking about issuing dev6 with all the pending fixes and
> having an extra dev7 next week before -final. Do you think such a change
> could be ready for dev6 so that people don't have to wait an extra week to
> test a change ?


The pending "use-service" code already embbed some changes in the
généric actions, like requirement of opaque data. So the change is easy
and the risk of regressions is low. In fact, the main complicated code
in the Lua is the runtime code and not the configuration parser nor
the registration of functions.

Thierry

Re: HAProxy/Lua survey about lua configuration form

[Thierry FOURNIER]

On Tue, 22 Sep 2015 22:18:10 -0400
Michael Ezzell  wrote:

> I don't see a significant problem, if there are benefits to be gained.
> 
> I assume part of the motivation is to prevent inadvertently calling an
> inappropriate function as an action, to perhaps to allow earlier validation
> of the configuration of actions referencing Lua functions, and to separate
> the namespaces of Lua functions and HAProxy Lua actions.
> 
> As long as no capabilities are lost or performance penalties are created, I
> don't see the change as being extreme.
> 
> One point that is not clear is how this "facilitates the distribution of
> Lua scripts for HAProxy."  You would need to look at the script to find the
> registered action name, the same as if you had to look at the script to
> find the function name... 


Sure, you're right. When I wrote this, I thought to an Lua file like an
addon with documentation who add some functions, perfectly defined. So,
with the registration function name based, an administrator can call
anything function, even bad functions.


> though perhaps the intention is to express the
> idea that "not every Lua function is appropriate to directly reference in
> the configuration" since there may be "private" functions in a script that
> are only intended to support other (exposed) functions, rather than being
> called directly.


Exactly.


> Perhaps you could provide more insight, particularly if I incorrect on some
> of these assumptions.  Otherwise, I don't see a reason to object (but I am
> not yet using Lua in production, so for me the change has minimal impact.)


I thought that I gave all the detail possibles. The change that I
proposes is just two things:

 - Add a call to the registration in lu Lua file,
   (core.action_register("name", function) ).

 - Change a little bit the configuration file:
   "http-request lua.name" instead of "http-request lua name"
   (only the 'dot' between "lua" and "name" who will become one word in
   place od two separate words).


Thierry


> On Sep 22, 2015 9:27 PM,  wrote:
> 
> > Hi list,
> >
> > Actually we two Lua registration forms:
> >
> > The style of fetches and converters (and coming soon the "services").
> > With this registering style, the Lua developer register the function in
> > the haproxy core like this:
> >
> >core.register_fetch("fetch-name", function(...)
> >   ... code ...
> >end)
> >
> > In the HAProxy configuration file, the registered Lua fetch can be used
> > like other fetch. it is automatically prefixed by "lua.". For example:
> >
> >use-backend service if { lua.fetch-name }
> >
> > The second mode is used with actions. Each action doesn't require any
> > registration. The user just give the Lua function name in the ha proxy
> > configuration. For example, in Lua file:
> >
> >function my_action(...)
> >   ... code ...
> >end
> >
> > And the associated HAProxy file:
> >
> >http-request lua my_action
> >
> > I want to remove the second declaration mode. After this the actions
> > will be registered like fetches and converters. The previous example
> > should become:
> >
> >core.register_action("action-name", function(...)
> >   ... code ...
> >end)
> >
> > And
> >
> >http-request lua.action-name
> >
> > I think that this mode of registration facilitates the distribution of
> > Lua scripts for HAProxy. The administrator doesn't look into the file
> > bout any function name, and the administrator cannot call a function
> > which is not designed for running in an HAProxy action.
> >
> > My problem, is that the second configuration mode exists in HAProxy
> > from a long time. I don't want to remove it without a consultation of
> > the people who already use this feature. My other problem, is that if
> > the version 1.6 is released with the second mode, we will keep (and
> > maintain) for a long time :)
> >
> > the discussion is open, please give me your opinions.
> >
> > Thierry
> >
> >

Re: Keeping conns alive on server side irrespective of client side conns

[Willy Tarreau]

On Wed, Sep 23, 2015 at 07:45:41PM +0530, Pradeep Jindal wrote:
> http-reuse won't serve the purpose here as it needs sessions to persist
> from client side for being able to reuse them for other sessions' requests.

Not exactly, it needs that *some* client connections persist, because each
server-side connection must be assigned to a client-side one at any moment.
If you run with 100% closed connections it will be useless, but if you have
even just a few percent of persistent front connections it will work pretty
well and considerably reduce the number of connections on your servers.

Regards,
Willy

Re: Keeping conns alive on server side irrespective of client side conns

[Pradeep Jindal]

I know, but that's totally dependant on what kind of clients one has online
and that's nondeterministic, but still can help.

- Pradeep Jindal

On Wed, Sep 23, 2015 at 10:07 PM, Willy Tarreau  wrote:

> On Wed, Sep 23, 2015 at 07:45:41PM +0530, Pradeep Jindal wrote:
> > http-reuse won't serve the purpose here as it needs sessions to persist
> > from client side for being able to reuse them for other sessions'
> requests.
>
> Not exactly, it needs that *some* client connections persist, because each
> server-side connection must be assigned to a client-side one at any moment.
> If you run with 100% closed connections it will be useless, but if you have
> even just a few percent of persistent front connections it will work pretty
> well and considerably reduce the number of connections on your servers.
>
> Regards,
> Willy
>
>

Re: HAProxy/Lua survey about lua configuration form

[Thierry FOURNIER]

Ok thank you for your opinions. The patch set is in attachment.

Thierry


On Wed, 23 Sep 2015 19:50:24 +0200
Willy Tarreau  wrote:

> On Wed, Sep 23, 2015 at 07:37:56PM +0200, Thierry FOURNIER wrote:
> > The pending "use-service" code already embbed some changes in the
> > généric actions, like requirement of opaque data. So the change is easy
> > and the risk of regressions is low. In fact, the main complicated code
> > in the Lua is the runtime code and not the configuration parser nor
> > the registration of functions.
> 
> OK, thanks for clarifying. Then indeed we should mostly focus on code
> reliability and correct behaviour and I agree that your proposal goes
> into that direction.
> 
> Willy
> 
> 
>From b8698194be79e095741a28e5a58dfacad80e2636 Mon Sep 17 00:00:00 2001
From: Thierry FOURNIER 
Date: Tue, 22 Sep 2015 18:26:42 +0200
Subject: [PATCH 1/3] MINOR: action: add private configuration

This private configuration pointer is used for storing some configuration
data associated the keyword, So many keywords can use the same parse
function, and this one can use a discriminator.
---
 include/types/action.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/types/action.h b/include/types/action.h
index 2461f79..d74e5ba 100644
--- a/include/types/action.h
+++ b/include/types/action.h
@@ -154,6 +154,7 @@ struct action_kw {
 	enum act_parse_ret (*parse)(const char **args, int *cur_arg, struct proxy *px,
 	struct act_rule *rule, char **err);
 	int match_pfx;
+	void *private;
 };
 
 struct action_kw_list {
-- 
2.1.4

>From fd4321b3824e84b789e2441e73399bf6c540e710 Mon Sep 17 00:00:00 2001
From: Thierry FOURNIER 
Date: Tue, 22 Sep 2015 19:14:35 +0200
Subject: [PATCH 2/3] MINOR: action: add reference to the original keywork
 matched for the called parser.

This is usefull because the keyword can contains some condifiguration
data set while the keyword registration.
---
 include/types/action.h | 1 +
 src/proto_http.c   | 2 ++
 src/proto_tcp.c| 3 +++
 3 files changed, 6 insertions(+)

diff --git a/include/types/action.h b/include/types/action.h
index d74e5ba..b7e1063 100644
--- a/include/types/action.h
+++ b/include/types/action.h
@@ -93,6 +93,7 @@ struct act_rule {
 	short deny_status; /* HTTP status to return to user when denying */
 	enum act_return (*action_ptr)(struct act_rule *rule, struct proxy *px,
 	  struct session *sess, struct stream *s); /* ptr to custom action */
+	struct action_kw *kw;
 	union {
 		struct {
 			char *realm;
diff --git a/src/proto_http.c b/src/proto_http.c
index 57cc354..9acf0a2 100644
--- a/src/proto_http.c
+++ b/src/proto_http.c
@@ -9442,6 +9442,7 @@ struct act_rule *parse_http_req_cond(const char **args, const char *file, int li
 		cur_arg = 1;
 		/* try in the module list */
 		rule->from = ACT_F_HTTP_REQ;
+		rule->kw = custom;
 		if (custom->parse(args, _arg, proxy, rule, ) == ACT_RET_PRS_ERR) {
 			Alert("parsing [%s:%d] : error detected in %s '%s' while parsing 'http-request %s' rule : %s.\n",
 			  file, linenum, proxy_type_str(proxy), proxy->id, args[0], errmsg);
@@ -9798,6 +9799,7 @@ struct act_rule *parse_http_res_cond(const char **args, const char *file, int li
 		cur_arg = 1;
 		/* try in the module list */
 		rule->from = ACT_F_HTTP_RES;
+		rule->kw = custom;
 		if (custom->parse(args, _arg, proxy, rule, ) == ACT_RET_PRS_ERR) {
 			Alert("parsing [%s:%d] : error detected in %s '%s' while parsing 'http-response %s' rule : %s.\n",
 			  file, linenum, proxy_type_str(proxy), proxy->id, args[0], errmsg);
diff --git a/src/proto_tcp.c b/src/proto_tcp.c
index e671e41..2ea7161 100644
--- a/src/proto_tcp.c
+++ b/src/proto_tcp.c
@@ -1435,6 +1435,7 @@ static int tcp_parse_response_rule(char **args, int arg, int section_type,
 		if (kw) {
 			arg++;
 			rule->from = ACT_F_TCP_RES_CNT;
+			rule->kw = kw;
 			if (kw->parse((const char **)args, , curpx, rule, err) == ACT_RET_PRS_ERR)
 return -1;
 		} else {
@@ -1636,9 +1637,11 @@ static int tcp_parse_request_rule(char **args, int arg, int section_type,
 		struct action_kw *kw;
 		if (where & SMP_VAL_FE_CON_ACC) {
 			kw = tcp_req_conn_action(args[arg]);
+			rule->kw = kw;
 			rule->from = ACT_F_TCP_REQ_CON;
 		} else {
 			kw = tcp_req_cont_action(args[arg]);
+			rule->kw = kw;
 			rule->from = ACT_F_TCP_REQ_CNT;
 		}
 		if (kw) {
-- 
2.1.4

>From 86dc0a15d0545731c02022c837a9407ec9f5910f Mon Sep 17 00:00:00 2001
From: Thierry FOURNIER 
Date: Wed, 23 Sep 2015 21:03:35 +0200
Subject: [PATCH 3/3] MINOR: lua: change actions registration

The current Lua action are not registered. The executed function is
selected according with a function name writed in the HAProxy configuration.

This patch add an action registration function. The configuration mode
described above disappear.

This change make some incompatibilities with existing 

Re: HAProxy/Lua survey about lua configuration form

[Willy Tarreau]

On Wed, Sep 23, 2015 at 09:09:09PM +0200, Thierry FOURNIER wrote:
> Ok thank you for your opinions. The patch set is in attachment.

Thanks. Is it for testing only or for applying ? Just let me know.

BTW I've started to sort out the applet issues, I guess I should be
able to produce something by tomorrow evening. No promises yet, there's
a surprize at the end of each wire I'm pulling, I feel like a fisherman!

Willy

Re: HAProxy/Lua survey about lua configuration form

[Thierry FOURNIER]

On Wed, 23 Sep 2015 21:15:08 +0200
Willy Tarreau  wrote:

> On Wed, Sep 23, 2015 at 09:09:09PM +0200, Thierry FOURNIER wrote:
> > Ok thank you for your opinions. The patch set is in attachment.
> 
> Thanks. Is it for testing only or for applying ? Just let me know.


You can apply these patch. There are tested.


Thierry

Re: HAProxy/Lua survey about lua configuration form

[Willy Tarreau]

On Wed, Sep 23, 2015 at 07:37:56PM +0200, Thierry FOURNIER wrote:
> The pending "use-service" code already embbed some changes in the
> généric actions, like requirement of opaque data. So the change is easy
> and the risk of regressions is low. In fact, the main complicated code
> in the Lua is the runtime code and not the configuration parser nor
> the registration of functions.

OK, thanks for clarifying. Then indeed we should mostly focus on code
reliability and correct behaviour and I agree that your proposal goes
into that direction.

Willy

Re: HAProxy/Lua survey about lua configuration form

[Willy Tarreau]

On Tue, Sep 22, 2015 at 10:18:10PM -0400, Michael Ezzell wrote:
> I don't see a significant problem, if there are benefits to be gained.
> 
> I assume part of the motivation is to prevent inadvertently calling an
> inappropriate function as an action, to perhaps to allow earlier validation
> of the configuration of actions referencing Lua functions, and to separate
> the namespaces of Lua functions and HAProxy Lua actions.

I'm seeing the same benefit. In fact I even *thought* that actions were
registered like fetch/convs. But the current state of affairs now scares
me for the future because indeed we don't want to call random functions
by accident. Also, I don't know if some functions are shipped with Lua,
but it could be painful if a new version of Lua brings new functions
which collide with ones that people use in their configs. With a
registration mechanism this cannot happen at all, so it's much safer.

It will also allow to use a wider character set in action names (eg: '-'
or '.' that we use in the core config language). So all in all I think it's
a good idea that's worth being done *before* the actual release otherwise
we could regret it later.

Thierry, what's the impact of such a change (in terms of complexity, amount
of code changed, risks of regressions, etc) ? I've found the issues I've been
debugging since last week-end, they're fixed on paper now, I just need to fix
the code and I'm thinking about issuing dev6 with all the pending fixes and
having an extra dev7 next week before -final. Do you think such a change
could be ready for dev6 so that people don't have to wait an extra week to
test a change ?

Thanks,
Willy

Re: Segfault on basic auth?

[Willy Tarreau]

Hi Phillip,

On Wed, Sep 23, 2015 at 12:59:05PM +0930, Phillip Decker wrote:
> Hi guys,
> 
> Not to pile on, but when running with 1.6-dev4, I've noticed a segfault
> that doesn't happen if you substitute 1.5.9 back in.  I can post more here
> later in the day, but I have a meeting to run to shortly-

(...)

I introduced a bug with the http-reuse which causes statuses 401 and 407
on http-server-close connections to dereference a NULL. It was fixed in
dev5. I'm pretty sure that's what you're seeing. Just update do dev5 or
better, latest snapshot, to confirm you don't see it anymore.

thanks,
Willy

Re: HAProxy/Lua survey about lua configuration form

[Willy Tarreau]

On Wed, Sep 23, 2015 at 09:26:33PM +0200, Thierry FOURNIER wrote:
> On Wed, 23 Sep 2015 21:15:08 +0200
> Willy Tarreau  wrote:
> 
> > On Wed, Sep 23, 2015 at 09:09:09PM +0200, Thierry FOURNIER wrote:
> > > Ok thank you for your opinions. The patch set is in attachment.
> > 
> > Thanks. Is it for testing only or for applying ? Just let me know.
> 
> 
> You can apply these patch. There are tested.

Merged, thanks!
Willy

Re: How to access Web products by their names in access url

[Bryan Talbot]

On Tue, Sep 22, 2015 at 12:06 AM, Susheel Jalali <
susheel.jal...@coscendcommunications.com> wrote:

> Access URL  
> http://CoscendCommunications.com/Product1
>
>
>
> Thank you.
>
> -
>
> frontend apps-frontend
>
> bind  *:80
>
> log   global
>
> optionforwardfor
>
> optionhttplog clf
>
> reqadd X-Forwarded-Proto:\ http
>

Probably better to use the nicer "http-request set-header" for new
configurations.



>
>
> acl host_subdomainP1 url_sub -i http://CoscendCommunications.com/Product1
>

You probably want to use the or 'path' matcher I think since you only seem
to care about the /Product1 portion to act on.




> use_backend subdomainP1 if host_subdomainP1
>
> default_backend apps-backend
>
>
>
> backend apps-backend
>
> log   global# use global settings
>
> balance   roundrobin
>
> optionhttpclose
>
> optionforwardfor
>
> http-request set-header X-Forwarded-Port %[dst_port]
>
> optionhttpchk HEAD / HTTP/1.1\r\nHost:localhost
>

This backend has no servers so will always return an error.

-Bryan

[PATCH] DeviceAtlas device detection update

[David Carlier]

Hello,

Apologies in advance for the verbosity of this message.
A set of patches (from 0001 to 0006) were made to make the DeviceAtlas
module handling multiple HTTP headers, converting the convertor to the
fetch function type and in the end introducing a new optional keyword entry.

In addition, in case it might be helpful,an independant patchset (made from
the master branch) to fix some modest memory leaks.

Please cc as well ttr...@deviceatlas.com for any response.

Kindest regards.

David Carlier.
From 41104700179c8e5d2c4ccaa6004aff0eabe9edf1 Mon Sep 17 00:00:00 2001
From: David CARLIER 
Date: Wed, 23 Sep 2015 20:08:27 +0100
Subject: [PATCH 1/6] Added new DeviceAtlas configuration keyword
 deviceatlas-cookie-name.

---
 doc/configuration.txt | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/doc/configuration.txt b/doc/configuration.txt
index aa00628..44ec896 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -653,6 +653,11 @@ deviceatlas-separator 
   Sets the character separator for the API properties results. This directive
   is optional and set to | by default if not set.
 
+devicatlas-properties-cookie 
+  Sets the client cookie's name used for the detection if the DeviceAtlas Client-side
+  component was used during the request. This directive is optional and set to
+  DAPROPS by default if not set.
+
 external-check
   Allows the use of an external agent to perform health checks.
   This is disabled by default as a security precaution.
@@ -11394,18 +11399,17 @@ crc32([])
   also "djb2", "sdbm", "wt6" and the "hash-type" directive.
 
 da-csv([,*])
-  Asks the DeviceAtlas converter to identify the User Agent string passed on
-  input, and to emit a string made of the concatenation of the properties
-  enumerated in argument, delimited by the separator defined by the global
-  keyword "deviceatlas-property-separator", or by default the pipe character
-  ('|'). There's a limit of 5 different properties imposed by the haproxy
+  Asks the DeviceAtlas converter to emit a string made of the concatenation of
+  the properties enumerated in argument, delimited by the separator defined by
+  the global keyword "deviceatlas-property-separator", or by default the pipe
+  character ('|'). There's a limit of 5 different properties imposed by the haproxy
   configuration language.
 
   Example:
 frontend www
 	bind *:8881
 	default_backend servers
-	http-request set-header X-DeviceAtlas-Data %[req.fhdr(User-Agent),da-csv(primaryHardwareType,osName,osVersion,browserName,browserVersion)]
+	http-request set-header X-DeviceAtlas-Data %[da-csv(primaryHardwareType,osName,osVersion,browserName,browserVersion)]
 
 debug
   This converter is used as debug tool. It dumps on screen the content and the
-- 
1.9.1

From 39b8e5bcb9c39bdd7a7242ec7b0ad370fe2bfd74 Mon Sep 17 00:00:00 2001
From: David CARLIER 
Date: Wed, 23 Sep 2015 20:10:10 +0100
Subject: [PATCH 2/6] Extracts two internal functions to iterate through the
 list of HTTP headers and to get if possible the specific client's cookie
 pushed by the DeviceAtlas Client-side component.

---
 include/proto/proto_http.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/proto/proto_http.h b/include/proto/proto_http.h
index 8385dc6..39717ed 100644
--- a/include/proto/proto_http.h
+++ b/include/proto/proto_http.h
@@ -94,7 +94,11 @@ int http_find_full_header2(const char *name, int len,
 int http_find_header2(const char *name, int len,
 		  char *sol, struct hdr_idx *idx,
 		  struct hdr_ctx *ctx);
+int http_find_next_header(char *sol, struct hdr_idx *idx,
+  struct hdr_ctx *ctx);
 char *find_hdr_value_end(char *s, const char *e);
+char *extract_cookie_value(char *hdr, const char *hdr_end, char *cookie_name,
+			   size_t cookie_name_l, int list, char **value, int *value_l);
 int http_header_match2(const char *hdr, const char *end, const char *name, int len);
 int http_remove_header2(struct http_msg *msg, struct hdr_idx *idx, struct hdr_ctx *ctx);
 int http_header_add_tail2(struct http_msg *msg, struct hdr_idx *hdr_idx, const char *text, int len);
-- 
1.9.1

From d7cb8acbb07e4474f4d6e1077e4b52bdd7f55ebc Mon Sep 17 00:00:00 2001
From: David CARLIER 
Date: Wed, 23 Sep 2015 20:11:35 +0100
Subject: [PATCH 3/6] As the DeviceAtlas fetch function handles all HTTP
 headers, no need anymore to store an user agent identifier,  a simple
 bitfield value suffices.

---
 include/types/global.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/types/global.h b/include/types/global.h
index cb04074..9842bce 100644
--- a/include/types/global.h
+++ b/include/types/global.h
@@ -180,10 +180,12 @@ struct global {
 	struct {
 		void *atlasimgptr;
 		char *jsonpath;
+		char *cookiename;
+		size_t cookienamelen;
 		da_atlas_t atlas;
-		da_evidence_id_t useragentid;
 		da_severity_t loglevel;
 		char separator;