urlp strange behaviour ?

[Laurent Penot]

HI,

I received URL from which i need to extract several parameters, I do that using 
urlp in lua. Values of parameters are urlencoded.
And I notice something strange : urlp seems to get only the first part of the 
value when the 2 char “;+” or “+;” are in the value of the parameter.

From the php point of view, using 
http://php.net/manual/en/function.urlencode.php , the 2 char “;+” or “+;” is 
valid in an urlencoded string.


Here are 2 tests URL and the dumped value from lua:
/dump_headers.php?p1=value1=word1+;word2=test
[info] 341/090330 (130491) : ua=word1+
The dumped value should be : word1+;word2

/dump_headers.php?p1=value1=word1;+word2=test
[info] 341/090951 (130491) : ua=word1
The dumped value should be : word1;+word2

Here is the haproxy config file (I removed everything not related to my 
question) :
global
debug
# lua file
lua-load url.lua

defaults
modehttp

frontend fe
bind :80
acl testurl url_beg /dump_headers.php
http-request lua.logValue if testurl
use_backend beok

backend beok
server mysrv 127.0.0.1:8080 check inter 1000ms fall 3 rise 1 weight 100


Here is the lua file :
core.register_action("logValue", {"http-req"}, function(txn)
local var = txn.f:urlp("ua");
core.Info("ua=" .. var);
end)



haproxy -vv
HA-Proxy version 1.6.2 2015/11/03
Copyright 2000-2015 Willy Tarreau 

Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
  OPTIONS = USE_ZLIB=1 USE_OPENSSL=1 USE_LUA=yes USE_DEVICEATLAS=1 USE_PCRE=1

Default settings :
  maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Encrypted password support via crypt(3): yes
Built with zlib version : 1.2.3
Compression algorithms supported : identity("identity"), deflate("deflate"), 
raw-deflate("deflate"), gzip("gzip")
Built with OpenSSL version : OpenSSL 1.0.2d 9 Jul 2015
Running on OpenSSL version : OpenSSL 1.0.2d 9 Jul 2015
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports prefer-server-ciphers : yes
Built with PCRE version : 7.8 2008-09-05
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Built with Lua version : Lua 5.3.1
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT 
IP_FREEBIND

Available polling systems :
  epoll : pref=300,  test result OK
   poll : pref=200,  test result OK
 select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Running on centos 6.
I notice the same thing with haproxy 1.6.1 and lua 5.3.1 or 5.3.0

Note : in the frontend, if I use : http-request set-header X-debugua 
%[urlp(ua)]
I get the same value as I get from Lua.


Can you tell me if I do something the wrong way or if it is a bug or if it is 
intended ?

Best regards
Laurent

Re: HAProxy disable retries

[Cyril Bonté]

Hi,

Le 08/12/2015 08:56, Yiannis Karayiannidis a écrit :

Hi all,
I have a strange HA Proxy *(**HAProxy version 1.5.2)* issue. i don't
really understand why.

I'm trying to disable the retries option from my haproxy. Since i've got
many POST requests

I've got in my conf the following two lines in my defaults section

 option redispatch
 retries 0

 contimeout 18
 clitimeout 18
 srvtimeout 18


but seems that the haproxy is retrying the connection after 18 sec
which is my default timeout:

Dec  7 11:57:22 haproxy-http1 haproxy[949]: xxx.xxx.xxx.xxx:64351
[07/Dec/2015:11:54:21.588] WEB-http-PORT-80 admin-backend/A1
785/0/0/-1/180787 -1 0 -- cD-- 841/169/1/1/0 0/0 "POST
/CloseOrCancelBatch HTTP/1.1"

Dec  7 12:00:22 haproxy-http1 haproxy[949]: xxx.xxx.xxx.xxx:64344
[07/Dec/2015:11:57:20.207] WEB-http-PORT-80 admin-backend/A1
2259/0/0/-1/182271 -1 0 - - cD-- 816/164/0/0/0 0/0 "POST
/CloseOrCancelBatch HTTP/1.1"

Dec  7 12:00:22 haproxy-http1 haproxy[949]: xxx.xxx.xxx.xxx:64352
[07/Dec/2015:12:00:21.468] WEB-http-PORT-80 admin-backend/A1
1104/0/0/24/1128 200 1876 - -  818/164/1/2/0 0/0 "POST
/CloseOrCancelBatch HTTP/1.1"


Could someone explain what am i doing wrong here?


The retry is made by your client, not haproxy.



Is there an option to disable retries only for POST requests which is a
bad thing in any case.

Regards
Yiannis




--
Cyril Bonté

Re: [1.6.1] Utilizing http-reuse

[Krishna Kumar (Engineering)]

Great! Initial tests shows that only one connection was established and
closed once.
The behavior is as follows:

telnet and a manual GET: Connection to haproxy and a connection to server
(port 2004).
Run ab: New connection to haproxy, reuse the same connection (Port 2004) to
server.
  'ab' finishes which results in client->haproxy connection getting
closed This results in
   immediate drop of haproxy->server connection (Port 2004) too.
Do another GET in the telnet: New connection is established from HAPRoxy ->
  server (port 2005).
Kill telnet: Connection to haproxy is killed. HAProxy kills port 2005
connection.

This behavior works for us, thanks a lot for the quick fix. The above
behavior
validates the second point you mentioned in your earlier mail:

"I'll see). If the client closes an idle connection while there are still
other connections left, the server connection is not moved back to the
server's idle list and is closed. It's not dramatic, but is a waste of
resources since we could maintain that connection open. I'll see if we can
do something simple regarding this case."

Thanks,
Krishna





.

On Tue, Dec 8, 2015 at 12:32 PM, Willy Tarreau  wrote:

> On Tue, Dec 08, 2015 at 07:44:45AM +0530, Krishna Kumar (Engineering)
> wrote:
> > Great, will be glad to test and report on the finding. Thanks!
>
> Sorry I forgot to post the patch after committing it. Here it comes.
> Regarding the second point, in the end it's not a bug, it's simply
> because we don't have connection pools yet, and I forgot that keeping
> an orphan backend connection was only possible with connection pools :-)
>
> Willy
>
>

Re: HAProxy disable retries

[Yiannis Karayiannidis]

How is it possible that the user made a retry
after exactly 3 minutes which is my timeout?
If you could see the timings it is 11:57:22  12:00:22

Regards
Yiannis

On Tue, Dec 8, 2015 at 10:27 AM, Cyril Bonté  wrote:

> Hi,
>
> Le 08/12/2015 08:56, Yiannis Karayiannidis a écrit :
>
>> Hi all,
>> I have a strange HA Proxy *(**HAProxy version 1.5.2)* issue. i don't
>> really understand why.
>>
>> I'm trying to disable the retries option from my haproxy. Since i've got
>> many POST requests
>>
>> I've got in my conf the following two lines in my defaults section
>>
>>  option redispatch
>>  retries 0
>>
>>  contimeout 18
>>  clitimeout 18
>>  srvtimeout 18
>>
>>
>> but seems that the haproxy is retrying the connection after 18 sec
>> which is my default timeout:
>>
>> Dec  7 11:57:22 haproxy-http1 haproxy[949]: xxx.xxx.xxx.xxx:64351
>> [07/Dec/2015:11:54:21.588] WEB-http-PORT-80 admin-backend/A1
>> 785/0/0/-1/180787 -1 0 -- cD-- 841/169/1/1/0 0/0 "POST
>> /CloseOrCancelBatch HTTP/1.1"
>>
>> Dec  7 12:00:22 haproxy-http1 haproxy[949]: xxx.xxx.xxx.xxx:64344
>> [07/Dec/2015:11:57:20.207] WEB-http-PORT-80 admin-backend/A1
>> 2259/0/0/-1/182271 -1 0 - - cD-- 816/164/0/0/0 0/0 "POST
>> /CloseOrCancelBatch HTTP/1.1"
>>
>> Dec  7 12:00:22 haproxy-http1 haproxy[949]: xxx.xxx.xxx.xxx:64352
>> [07/Dec/2015:12:00:21.468] WEB-http-PORT-80 admin-backend/A1
>> 1104/0/0/24/1128 200 1876 - -  818/164/1/2/0 0/0 "POST
>> /CloseOrCancelBatch HTTP/1.1"
>>
>>
>> Could someone explain what am i doing wrong here?
>>
>
> The retry is made by your client, not haproxy.
>
>
>
>> Is there an option to disable retries only for POST requests which is a
>> bad thing in any case.
>>
>> Regards
>> Yiannis
>>
>>
>
> --
> Cyril Bonté
>

DRAIN status

[bjun...@gmail.com]

Hi,

when a healthcheck ("fall 2") on a backend server is failing, the status of
the backend is changing to "DRAIN 1/2"  (I do not manually set the DRAIN
state nor do i have agent-check's)

Does that mean that for the period till the next healthcheck, the server is
completely removed from load balancing? (or is "DRAIN" misleading here?)

HAProxy Version: 1.5.14

-
Best Regards

Bjoern

Re: urlp strange behaviour ?

[Thierry FOURNIER]

Hi,

I agree with you, but in HAProxy, the ';' is considered as parameter
delimiter. Its hardcoded, and I don't known the reason.

So the behaviour that you observe is the normal HAProxy behaviour.

Thierry



On Tue, 8 Dec 2015 09:17:38 +
Laurent Penot  wrote:

> HI,
> 
> I received URL from which i need to extract several parameters, I do that 
> using urlp in lua. Values of parameters are urlencoded.
> And I notice something strange : urlp seems to get only the first part of the 
> value when the 2 char “;+” or “+;” are in the value of the parameter.
> 
> From the php point of view, using 
> http://php.net/manual/en/function.urlencode.php , the 2 char “;+” or “+;” is 
> valid in an urlencoded string.
> 
> 
> Here are 2 tests URL and the dumped value from lua:
> /dump_headers.php?p1=value1=word1+;word2=test
> [info] 341/090330 (130491) : ua=word1+
> The dumped value should be : word1+;word2
> 
> /dump_headers.php?p1=value1=word1;+word2=test
> [info] 341/090951 (130491) : ua=word1
> The dumped value should be : word1;+word2
> 
> Here is the haproxy config file (I removed everything not related to my 
> question) :
> global
> debug
> # lua file
> lua-load url.lua
> 
> defaults
> modehttp
> 
> frontend fe
> bind :80
> acl testurl url_beg /dump_headers.php
> http-request lua.logValue if testurl
> use_backend beok
> 
> backend beok
> server mysrv 127.0.0.1:8080 check inter 1000ms fall 3 rise 1 weight 100
> 
> 
> Here is the lua file :
> core.register_action("logValue", {"http-req"}, function(txn)
> local var = txn.f:urlp("ua");
> core.Info("ua=" .. var);
> end)
> 
> 
> 
> haproxy -vv
> HA-Proxy version 1.6.2 2015/11/03
> Copyright 2000-2015 Willy Tarreau 
> 
> Build options :
>   TARGET  = linux2628
>   CPU = generic
>   CC  = gcc
>   CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
>   OPTIONS = USE_ZLIB=1 USE_OPENSSL=1 USE_LUA=yes USE_DEVICEATLAS=1 USE_PCRE=1
> 
> Default settings :
>   maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
> 
> Encrypted password support via crypt(3): yes
> Built with zlib version : 1.2.3
> Compression algorithms supported : identity("identity"), deflate("deflate"), 
> raw-deflate("deflate"), gzip("gzip")
> Built with OpenSSL version : OpenSSL 1.0.2d 9 Jul 2015
> Running on OpenSSL version : OpenSSL 1.0.2d 9 Jul 2015
> OpenSSL library supports TLS extensions : yes
> OpenSSL library supports SNI : yes
> OpenSSL library supports prefer-server-ciphers : yes
> Built with PCRE version : 7.8 2008-09-05
> PCRE library supports JIT : no (USE_PCRE_JIT not set)
> Built with Lua version : Lua 5.3.1
> Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT 
> IP_FREEBIND
> 
> Available polling systems :
>   epoll : pref=300,  test result OK
>poll : pref=200,  test result OK
>  select : pref=150,  test result OK
> Total: 3 (3 usable), will use epoll.
> 
> Running on centos 6.
> I notice the same thing with haproxy 1.6.1 and lua 5.3.1 or 5.3.0
> 
> Note : in the frontend, if I use : http-request set-header X-debugua 
> %[urlp(ua)]
> I get the same value as I get from Lua.
> 
> 
> Can you tell me if I do something the wrong way or if it is a bug or if it is 
> intended ?
> 
> Best regards
> Laurent
> 
> 
> 

[SPAM] Bénéficiez de 2 mois offerts sur votre contrat santé

[Eovi Mcd Mutuelle via LPM]

Pour Eovi mutuelle, vous n'êtes pas un numéro;
Pour Eovi Mcd mutuelle, je ne suis pas un numéro.
Pour Eovi Mcd vous n’êtes pas un numéro.
Nous nous adaptons à vos besoins personnels et
à votre budget pour une protection santé qui vous correspond.
* Offre valable du 1 septembre 2015 au 31 janvier 2016 pour tout nouvel 
adhérent souscrivant un contrat santé de la gamme Equitéo, Territéo, Tonus pro, 
Vital et Hospitéo. Les 2 mois de gratuité sont répartis comme suit : 1 mois la 
1ère année d’adhésion et 1 mois la 2ème. Voir conditions et limitations de 
l’offre en agence Eovi Mcd mutuelle. (1) Formule EQUITEO Essentiel HOSPI pour 
une personne née en 1997 et résidant dans le département 71. Tarif en vigueur 
jusqu´au 31/12/2015.
Conformément à la loi Informatique et Libertés n° 78-17 du 6 janvier 1978, 
modifiée le 6 août 2004, vous bénéficiez d'un droit d'accès, de modification et 
de suppression des informations qui vous concernent.
Eovi Mcd mutuelle. Siège social Eovi Mcd mutuelle : 44 rue Copernic - CS 11709 
- 75773 Paris Cedex 16.
Mutuelle soumise aux dispositions du livre II du Code de la mutualité, N° 
Sirène 317 442 176.

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]

fix my patch formation :)



doc.patch
Description: Binary data


--
Good day!
ruoshan

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

[Willy Tarreau]

On Tue, Dec 08, 2015 at 09:12:45PM +0800, Ruoshan Huang wrote:
> fix my patch formation :)

Perfect, I've just merged it now in both 1.7 and 1.6, thank you!

Willy

Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

[Dave Zhu (yanbzhu)]

Thanks for posting this.

I’m looking into it.

-Dave

From: Bryan Talbot >
Date: Monday, December 7, 2015 at 5:58 PM
To: Willy Tarreau >
Cc: Yanbo Zhu >, Olivier Doucet 
>, Emeric Brun 
>, Lukas Tribus 
>, Remi Gacogne 
>, Nenad Merdanovic 
>, 
"haproxy@formilux.org" 
>, Bryan Talbot 
>
Subject: Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

Glad you were able to get to the bottom of the crash.

With the newest 5 patches, I'm still not seeing the behavior I am expecting. To 
make my testing and expectations hopefully more clear, I've pushed them to 
github (https://github.com/btalbot/dual-stack-test)  From a laptop with Vagrant 
installed, it should be a simple process to provision a host for testing and 
run the test script.

What I am expecting is that OpenSSL 0.9.8 client will be able to connect to an 
haproxy port that is bound to both ECDSA and RSA certificates. This doesn't 
work for me and the connection fails the SSL handshake.

I'm also expecting that a newer OpenSSL which support ECC will connect AND 
negotiate and use the 256 bit ECDSA certificate and not the RSA cert. My tests 
always show the ECC capable client still getting the RSA certificate.



-Bryan




On Mon, Dec 7, 2015 at 1:44 PM, Willy Tarreau > 
wrote:
On Mon, Dec 07, 2015 at 08:48:53PM +, Dave Zhu (yanbzhu) wrote:
> Hey Willy
>
> On 12/7/15, 3:11 PM, "Willy Tarreau" > wrote:
> >
> >Yep, thanks for the pointer. So indeed gcc's inline version of strncpy
> >*is*
> >bogus. strncpy() has no right to guess the destination size.
> >
> >I suspect that if you just do this it would work (prefix the array with
> >'&'
> >and use [0] :
> >
> >   strncpy((char *)_kt->name.key[0], trash.str, i);
> >
> >Thanks,
> >Willy
>
> You would be correct in this guess :)
>
> So what零 the preference? Should I change it to use this weird version of
> strcpy, or change it to memcpy?

I'd prefer the memcpy() anyway. Please keep your comment and add the
link to gcc's bugzilla so that nobody is tempted to change this later
for any reason, and please mention that it's the inlined version of
strncpy() which refuses to write into a char[0].

You have my full support if you want to add some dirty words there to
express your feelings about the compiler which dies on valid C code...

Thanks,
Willy

Re: New discussion platform to exchange and discuss configurations

[Jeff Palmer]

Nice work,   and a thank you to Atwood!


Occasionally I see (or help people) with haproxy configs on reddit.
some of them may be useful as config examples in the new discourse
site.

As a matter of preference,  would you prefer we describe the config
example, and then link to the reddit post (or thread)  or would you
prefer a description and a cut/paste of the config example directly
into the new discourse space?

An example for reference:

A total HAProxy newcomer wants to use haproxy in his home lab.  had a
handful of basic questions.  I typed up a basic config to get him
started in 1 of 2 scenarios (using DNS hostnames, or not)
My response with config examples is here:
https://www.reddit.com/r/homelab/comments/3vmktv/haproxy_setup/cxrk16k

Would like to know how you'd prefer this kind of scenario to be handled.


On Tue, Dec 8, 2015 at 9:51 AM, Willy Tarreau  wrote:
> Hi all,
>
> as I already mentionned, a few months ago Jeff Atwood, the original
> founder of StackOverflow and more recently Discourse offered us a
> 100% free hosting of whatever discussions we want on the Discourse
> platform.
>
> It came just at the right time because I predicted that we would
> start to see people want to share some Lua scripts and the mailing
> list is not suited to this. It's not easy to search a mailing list's
> archives nor is it to have a quick index to existing contents.
>
> Over last week-end, Jeff and Neil helped me set up something to start
> with. I found that it would also make sense to share some configurations
> so that people can participate in improving some possible templates
> resulting in less issues being reported here.
>
> Let me remind you that I'm a total dumbass when it comes to trying to
> achieve anything using a web browser. So I did what appeared logical
> and intuitive enough to me, that might not match your taste. Comments
> are welcome.
>
> The site is organized in categories. For now there are only 3, we'll
> see how things go and may add more depending on feedback :
>   - site feedback : report any suggestion or issue with the site.
>   - configuration samples : place where people can discuss and share
> configurations.
>   - Lua scripts : same for Lua scripts
>
> Maybe later we'll add an "articles" section so that people can share
> their experience by writing articles about certain subjects. We may
> also add a "junk" or "test" category for those who just want to run
> some tests, but this will probably require an automatic cleanup and
> I don't know if we can do that yet.
>
> In order to start a discussion, either you find a topic which matches
> your discussion and you participate to it, or you create a new topic.
> Please try to be as clear as possible and avoid creating tons of useless
> topics.
>
> We have the possibility to have several administrator accounts, so once
> things are on the right tracks and some participants show a great
> involvement, I'll propose to some of them to become admins.
>
> Please, do not use this platform to report bugs or seek for some
> assistance for now, that's not the purpose. This may change in the
> future when admins share the management effort, but one thing at a
> time please.
>
> So please test it, send your feedback there in the site feedback
> category. Be gentle with me, I'm debuting :-)
>
> The URL for this new platform is http://discourse.haproxy.org/
>
> Thanks to Discourse for this!
> Willy
>
>



-- 
Jeff Palmer
https://PalmerIT.net

New discussion platform to exchange and discuss configurations

[Willy Tarreau]

Hi all,

as I already mentionned, a few months ago Jeff Atwood, the original
founder of StackOverflow and more recently Discourse offered us a
100% free hosting of whatever discussions we want on the Discourse
platform.

It came just at the right time because I predicted that we would
start to see people want to share some Lua scripts and the mailing
list is not suited to this. It's not easy to search a mailing list's
archives nor is it to have a quick index to existing contents.

Over last week-end, Jeff and Neil helped me set up something to start
with. I found that it would also make sense to share some configurations
so that people can participate in improving some possible templates
resulting in less issues being reported here.

Let me remind you that I'm a total dumbass when it comes to trying to
achieve anything using a web browser. So I did what appeared logical
and intuitive enough to me, that might not match your taste. Comments
are welcome.

The site is organized in categories. For now there are only 3, we'll
see how things go and may add more depending on feedback :
  - site feedback : report any suggestion or issue with the site.
  - configuration samples : place where people can discuss and share
configurations.
  - Lua scripts : same for Lua scripts

Maybe later we'll add an "articles" section so that people can share
their experience by writing articles about certain subjects. We may
also add a "junk" or "test" category for those who just want to run
some tests, but this will probably require an automatic cleanup and
I don't know if we can do that yet.

In order to start a discussion, either you find a topic which matches
your discussion and you participate to it, or you create a new topic.
Please try to be as clear as possible and avoid creating tons of useless
topics.

We have the possibility to have several administrator accounts, so once
things are on the right tracks and some participants show a great
involvement, I'll propose to some of them to become admins.

Please, do not use this platform to report bugs or seek for some
assistance for now, that's not the purpose. This may change in the
future when admins share the management effort, but one thing at a
time please.

So please test it, send your feedback there in the site feedback
category. Be gentle with me, I'm debuting :-)

The URL for this new platform is http://discourse.haproxy.org/

Thanks to Discourse for this!
Willy

Re: New discussion platform to exchange and discuss configurations

[Willy Tarreau]

On Tue, Dec 08, 2015 at 10:18:27AM -0500, Jeff Palmer wrote:
Hi Jeff,

> Occasionally I see (or help people) with haproxy configs on reddit.
> some of them may be useful as config examples in the new discourse
> site.
> 
> As a matter of preference,  would you prefer we describe the config
> example, and then link to the reddit post (or thread)  or would you
> prefer a description and a cut/paste of the config example directly
> into the new discourse space?
> 
> An example for reference:
> 
> A total HAProxy newcomer wants to use haproxy in his home lab.  had a
> handful of basic questions.  I typed up a basic config to get him
> started in 1 of 2 scenarios (using DNS hostnames, or not)
> My response with config examples is here:
> https://www.reddit.com/r/homelab/comments/3vmktv/haproxy_setup/cxrk16k
> 
> Would like to know how you'd prefer this kind of scenario to be handled.

Linking only might make it difficult to people to suggest adaptations.
Copying will make it difficult for people on reddit to know there are
updates. And it's in general not nice to "steal" contents between sites.

I think the best way to deal with this then is to import the config
and to mention in the post where it was found. This way the link to the
original post is not lost and any potential update on the original site
can be found. The original poster and/or site remains credited for the
initial post, which is important to ensure people continue to freely
exchange.

Thanks,
Willy

Re: New discussion platform to exchange and discuss configurations

[Jeff Palmer]

This makes sense,  and follows the stackexchange/stackoverflow convention.


They basically Link to the location where the info was originally
posted, but also copy the relevant content into the reply.



On Tue, Dec 8, 2015 at 10:42 AM, Willy Tarreau  wrote:
> On Tue, Dec 08, 2015 at 10:18:27AM -0500, Jeff Palmer wrote:
> Hi Jeff,
>
>> Occasionally I see (or help people) with haproxy configs on reddit.
>> some of them may be useful as config examples in the new discourse
>> site.
>>
>> As a matter of preference,  would you prefer we describe the config
>> example, and then link to the reddit post (or thread)  or would you
>> prefer a description and a cut/paste of the config example directly
>> into the new discourse space?
>>
>> An example for reference:
>>
>> A total HAProxy newcomer wants to use haproxy in his home lab.  had a
>> handful of basic questions.  I typed up a basic config to get him
>> started in 1 of 2 scenarios (using DNS hostnames, or not)
>> My response with config examples is here:
>> https://www.reddit.com/r/homelab/comments/3vmktv/haproxy_setup/cxrk16k
>>
>> Would like to know how you'd prefer this kind of scenario to be handled.
>
> Linking only might make it difficult to people to suggest adaptations.
> Copying will make it difficult for people on reddit to know there are
> updates. And it's in general not nice to "steal" contents between sites.
>
> I think the best way to deal with this then is to import the config
> and to mention in the post where it was found. This way the link to the
> original post is not lost and any potential update on the original site
> can be found. The original poster and/or site remains credited for the
> initial post, which is important to ensure people continue to freely
> exchange.
>
> Thanks,
> Willy
>



-- 
Jeff Palmer
https://PalmerIT.net

In dash car dvd player

[lenn...@163.com]

Hi
This is Lenny Su from Shenzhen ZYC Car Electronic Co.,Ltd.!
We are factory in Shenzhen China specializing in Car DVD player product!
Our product:
V.W/ TOYOTA/HONDA/KIA/HYUNDAI/FORD/CHERY/CHEVELET   OE-FIT player 
with NAVIGATIOR and Capacity touch panel with both WIN CE and Andriod OS.
6.2"/ 7"/ 6.95" 2-DIN universal car DVD palyer with Capacity multi-touch 
panel and both Win CE 6.0 and Andriod 4.4 OS.
More infos, plz feel free to contact us for further information!
Br
LennySu
General Manager
ZYC Car Electronic Co.,Ltd.
3th Floor of Chuangcheng Electronic Building, Taiwan Industrial Park, Shiyan, 
Bao'an District, Shenzhen, P.R.China.
Ph:+86-158-147-45839  
Tel:+86-755-27655597    Fax:+86-755-27655943
Email: lenn...@163.com

Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

[Dave Zhu (yanbzhu)]

Hey Bryan,

I believe I have gotten to the bottom of the behavior that you are seeing:


  1.  0.9.8 client cannot connect to dual cert port: This was a bug on my part. 
I neglected to set a DHE keys for the SSL_CTX with multiple certs. I’ve 
attached another set of patches (1-5 are identical, 6 is new) that fixes this.
  2.  ECC capable client does not use ECC cipher: I believe this is due to your 
test configuration. Openssl prefers RSA ciphers by default, and so if you don’t 
specify an ECC cipher first, it will always pick an RSA cipher. Your test uses 
"./openssl-1.0.2e/apps/openssl s_client -connect 127.0.0.1:8443” as the 
command, which will use the default cipher list. Try specifying an ECC cipher 
as the first cipher and it should work.

Please take a look.

-Dave

From: Bryan Talbot >
Date: Monday, December 7, 2015 at 5:58 PM
To: Willy Tarreau >
Cc: Yanbo Zhu >, Olivier Doucet 
>, Emeric Brun 
>, Lukas Tribus 
>, Remi Gacogne 
>, Nenad Merdanovic 
>, 
"haproxy@formilux.org" 
>, Bryan Talbot 
>
Subject: Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

Glad you were able to get to the bottom of the crash.

With the newest 5 patches, I'm still not seeing the behavior I am expecting. To 
make my testing and expectations hopefully more clear, I've pushed them to 
github (https://github.com/btalbot/dual-stack-test)  From a laptop with Vagrant 
installed, it should be a simple process to provision a host for testing and 
run the test script.

What I am expecting is that OpenSSL 0.9.8 client will be able to connect to an 
haproxy port that is bound to both ECDSA and RSA certificates. This doesn't 
work for me and the connection fails the SSL handshake.

I'm also expecting that a newer OpenSSL which support ECC will connect AND 
negotiate and use the 256 bit ECDSA certificate and not the RSA cert. My tests 
always show the ECC capable client still getting the RSA certificate.



-Bryan




On Mon, Dec 7, 2015 at 1:44 PM, Willy Tarreau > 
wrote:
On Mon, Dec 07, 2015 at 08:48:53PM +, Dave Zhu (yanbzhu) wrote:
> Hey Willy
>
> On 12/7/15, 3:11 PM, "Willy Tarreau" > wrote:
> >
> >Yep, thanks for the pointer. So indeed gcc's inline version of strncpy
> >*is*
> >bogus. strncpy() has no right to guess the destination size.
> >
> >I suspect that if you just do this it would work (prefix the array with
> >'&'
> >and use [0] :
> >
> >   strncpy((char *)_kt->name.key[0], trash.str, i);
> >
> >Thanks,
> >Willy
>
> You would be correct in this guess :)
>
> So what零 the preference? Should I change it to use this weird version of
> strcpy, or change it to memcpy?

I'd prefer the memcpy() anyway. Please keep your comment and add the
link to gcc's bugzilla so that nobody is tempted to change this later
for any reason, and please mention that it's the inlined version of
strncpy() which refuses to write into a char[0].

You have my full support if you want to add some dirty words there to
express your feelings about the compiler which dies on valid C code...

Thanks,
Willy




0001-MINOR-ssl-Added-cert_key_and_chain-struct.patch
Description: 0001-MINOR-ssl-Added-cert_key_and_chain-struct.patch


0002-MEDIUM-ssl-Added-support-for-creating-SSL_CTX-with-m.patch
Description: 0002-MEDIUM-ssl-Added-support-for-creating-SSL_CTX-with-m.patch


0003-MINOR-ssl-Added-multi-cert-support-for-crt-list-conf.patch
Description: 0003-MINOR-ssl-Added-multi-cert-support-for-crt-list-conf.patch


0004-BUG-MINOR-ssl-Fixed-code-that-crashed-under-optimiza.patch
Description: 0004-BUG-MINOR-ssl-Fixed-code-that-crashed-under-optimiza.patch


0005-MINOR-ssl-Clean-up-unused-code-fixed-spelling-error.patch
Description: 0005-MINOR-ssl-Clean-up-unused-code-fixed-spelling-error.patch


0006-BUG-MINOR-ssl-Fixed-error-where-multi-certs-didn-t-s.patch
Description: 0006-BUG-MINOR-ssl-Fixed-error-where-multi-certs-didn-t-s.patch

Re: urlp strange behaviour ?

[Laurent Penot]

Thx for your answer Thierry.

If you try with the URI : 
/dump_headers.php?p1=value1=word1;word2;word3=test

Urlp called in haproxy configuration will return : “word1” which corresponds to 
your answer.
But if you use urlp from lua, it will return you the correct value, see my dump 
:
[info] 341/214152 (2580) : ua=word1;word2;word3

The difference of answer between theses 2 urlp call looks strange from my side.
As far as I know, a parameter value starts after the “=“ and ends either at the 
first “&” encoutered or at the end of the URI.

So using urlp from lua, I thing there is only something wrong when there is 
“;+” or “+;” in the value of the parameter.
Using urlp from haproxy should have the same behaviour as using urlp from lua.

Does that make sense ? Or I’m really mistaken ?

Best
Laurent







On 08/12/15 11:23, "Thierry FOURNIER"  wrote:

>Hi,
>
>I agree with you, but in HAProxy, the ';' is considered as parameter
>delimiter. Its hardcoded, and I don't known the reason.
>
>So the behaviour that you observe is the normal HAProxy behaviour.
>
>Thierry
>
>
>
>On Tue, 8 Dec 2015 09:17:38 +
>Laurent Penot  wrote:
>
>> HI,
>> 
>> I received URL from which i need to extract several parameters, I do that 
>> using urlp in lua. Values of parameters are urlencoded.
>> And I notice something strange : urlp seems to get only the first part of 
>> the value when the 2 char “;+” or “+;” are in the value of the parameter.
>> 
>> From the php point of view, using 
>> http://php.net/manual/en/function.urlencode.php , the 2 char “;+” or “+;” is 
>> valid in an urlencoded string.
>> 
>> 
>> Here are 2 tests URL and the dumped value from lua:
>> /dump_headers.php?p1=value1=word1+;word2=test
>> [info] 341/090330 (130491) : ua=word1+
>> The dumped value should be : word1+;word2
>> 
>> /dump_headers.php?p1=value1=word1;+word2=test
>> [info] 341/090951 (130491) : ua=word1
>> The dumped value should be : word1;+word2
>> 
>> Here is the haproxy config file (I removed everything not related to my 
>> question) :
>> global
>> debug
>> # lua file
>> lua-load url.lua
>> 
>> defaults
>> modehttp
>> 
>> frontend fe
>> bind :80
>> acl testurl url_beg /dump_headers.php
>> http-request lua.logValue if testurl
>> use_backend beok
>> 
>> backend beok
>> server mysrv 127.0.0.1:8080 check inter 1000ms fall 3 rise 1 weight 100
>> 
>> 
>> Here is the lua file :
>> core.register_action("logValue", {"http-req"}, function(txn)
>> local var = txn.f:urlp("ua");
>> core.Info("ua=" .. var);
>> end)
>> 
>> 
>> 
>> haproxy -vv
>> HA-Proxy version 1.6.2 2015/11/03
>> Copyright 2000-2015 Willy Tarreau 
>> 
>> Build options :
>>   TARGET  = linux2628
>>   CPU = generic
>>   CC  = gcc
>>   CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
>>   OPTIONS = USE_ZLIB=1 USE_OPENSSL=1 USE_LUA=yes USE_DEVICEATLAS=1 USE_PCRE=1
>> 
>> Default settings :
>>   maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
>> 
>> Encrypted password support via crypt(3): yes
>> Built with zlib version : 1.2.3
>> Compression algorithms supported : identity("identity"), deflate("deflate"), 
>> raw-deflate("deflate"), gzip("gzip")
>> Built with OpenSSL version : OpenSSL 1.0.2d 9 Jul 2015
>> Running on OpenSSL version : OpenSSL 1.0.2d 9 Jul 2015
>> OpenSSL library supports TLS extensions : yes
>> OpenSSL library supports SNI : yes
>> OpenSSL library supports prefer-server-ciphers : yes
>> Built with PCRE version : 7.8 2008-09-05
>> PCRE library supports JIT : no (USE_PCRE_JIT not set)
>> Built with Lua version : Lua 5.3.1
>> Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT 
>> IP_FREEBIND
>> 
>> Available polling systems :
>>   epoll : pref=300,  test result OK
>>poll : pref=200,  test result OK
>>  select : pref=150,  test result OK
>> Total: 3 (3 usable), will use epoll.
>> 
>> Running on centos 6.
>> I notice the same thing with haproxy 1.6.1 and lua 5.3.1 or 5.3.0
>> 
>> Note : in the frontend, if I use : http-request set-header X-debugua 
>> %[urlp(ua)]
>> I get the same value as I get from Lua.
>> 
>> 
>> Can you tell me if I do something the wrong way or if it is a bug or if it 
>> is intended ?
>> 
>> Best regards
>> Laurent
>> 
>> 
>> 

Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

[Bryan Talbot]

On Tue, Dec 8, 2015 at 11:18 AM, Dave Zhu (yanbzhu) 
wrote:

> Hey Bryan,
>
> I believe I have gotten to the bottom of the behavior that you are seeing:
>
>
>1. 0.9.8 client cannot connect to dual cert port: This was a bug on my
>part. I neglected to set a DHE keys for the SSL_CTX with multiple certs.
>I’ve attached another set of patches (1-5 are identical, 6 is new) that
>fixes this.
>
>
yep, patch 6 fixes this problem for me.



>
>1. ECC capable client does not use ECC cipher: I believe this is due
>to your test configuration. Openssl prefers RSA ciphers by default, and so
>if you don’t specify an ECC cipher first, it will always pick an RSA
>cipher. Your test uses "./openssl-1.0.2e/apps/openssl s_client -connect
>127.0.0.1:8443” as the command, which will use the default cipher
>list. Try specifying an ECC cipher as the first cipher and it should work.
>
>
Of course, I should have realized that too. I've updated the bind ciphers
to prioritize ECDSA over RSA and that fixes the issue. So the basic tests I
defined before are all passing now but only when the crt line specifies a
"pem" file that doesn't exist and .ecdsa / .rsa files are loaded from that
base.


Now, about using the crt bind option with a directory of certs
https://cbonte.github.io/haproxy-dconv/configuration-1.6.html#crt (Bind
options)

How should that work, especially if there are .ocsp and .issuer data in the
crt directory? Currently, the ECDSA certificate seems to always be used
even for non-ECC capable clients but I suspect that's due to the .ecdsa
cert being loaded first and your patches do not cover that use case yet.



-Bryan

Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

[Willy Tarreau]

On Tue, Dec 08, 2015 at 10:32:02PM +, Dave Zhu (yanbzhu) wrote:
> Hey Willy,
> 
> On 12/8/15, 5:27 PM, "Willy Tarreau"  wrote:
> >
> >In my opinion, these suffixes should be used only after the real cert
> >file name. So when you load "foobar.ecdsa", you should only consider
> >"foobar.ecdsa.ocsp" and so on. And from what I remember, on the CLI
> >we mention the cert name when feeding an OCSP entry so that should
> >continue to work perfectly.
> 
> I agree, the limitation here is that the way HAProxy is current designed
> only allows for 1 OCSP staple per SSL_CTX. This will have to change to
> multiple staples for SSL_CTX¹s with multiple certs.

Ah, I thought each cert had its own SSL_CTX. But don't worry for my
understanding of this complex API... my understanding dances like the
light of a candle in the wind. Others (like you) seem to have powerful
spots instead :-)

> >I do think so. We'll just have to remerge 4, 5 and 6 into their respective
> >patches (2 apparently) and we're good to go. If Emeric doesn't raise any
> >objection (apparently you addressed his concerns) I can merge all that
> >myself.
> >If you prefer to remerge the patches above yourself, no problem for me.
> 
> I can remerge everything into 3 patches, it will be cleaner that way. I¹ll
> send them out tomorrow.

Perfect, thanks!
Willy

Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

[Willy Tarreau]

Hi Dave,

On Tue, Dec 08, 2015 at 09:12:58PM +, Dave Zhu (yanbzhu) wrote:
> There are also 2 issues here.
> 
> 
>   1.  Loading certs from a directory doesn't process multiple certs at the
>   same time. This I can fix with another patch to add that functionality

I didn't think about this one indeed.

>   2.  .issuer, .ocsp and .sctl only apply to a single cert, not multiple
>   certs. This is tricker, since we'd have to load multiple OCSP responses for
>   stapling in the case of multiple certs, which would mean that we would have
>   to set the OCSP response based on which certificate is presented. I could
>   look into this as well, since it shouldn't be impossible to do given
>   current HAProxy infrastructure. However, I would prefer that the
>   functionality as it is today makes it into the code base. Similar with
>   SCTL, although I have zero experience in that matter and would need
>   guidance.

In my opinion, these suffixes should be used only after the real cert
file name. So when you load "foobar.ecdsa", you should only consider
"foobar.ecdsa.ocsp" and so on. And from what I remember, on the CLI
we mention the cert name when feeding an OCSP entry so that should
continue to work perfectly.

> I'll look into #1 and the ocsp portion of #2. I'll let you know when I have 
> updates.
> 
> In the mean time, is the code and functionality as of today acceptable? Could
> the feature be merged as is, with features added in the future?

I do think so. We'll just have to remerge 4, 5 and 6 into their respective
patches (2 apparently) and we're good to go. If Emeric doesn't raise any
objection (apparently you addressed his concerns) I can merge all that myself.
If you prefer to remerge the patches above yourself, no problem for me.

Thanks !
Willy

Re: urlp strange behaviour ?

[Aleksandar Lazic]

Hi.

Am 08-12-2015 11:23, schrieb Thierry FOURNIER:

Hi,

I agree with you, but in HAProxy, the ';' is considered as parameter
delimiter. Its hardcoded, and I don't known the reason.


There are several reasons for the ';' to be a separator similar like 
'&'.


http://www.skorks.com/2010/05/what-every-developer-should-know-about-urls/
http://www.w3.org/TR/html401/appendix/notes.html#h-B.2.2

As far as I remember almost every Appserver add a ';session=' to 
the URL when the server detects that the client does not accept cookies.


http://javarevisited.blogspot.co.at/2012/08/what-is-jsessionid-in-j2ee-web.html
http://www.php.net/manual/en/session.configuration.php#ini.session.use-trans-sid
http://www.programmerinterview.com/index.php/php-questions/can-sessions-work-without-cookies/

BR
Aleks


So the behaviour that you observe is the normal HAProxy behaviour.

Thierry



On Tue, 8 Dec 2015 09:17:38 +
Laurent Penot  wrote:


HI,

I received URL from which i need to extract several parameters, I do 
that using urlp in lua. Values of parameters are urlencoded.
And I notice something strange : urlp seems to get only the first part 
of the value when the 2 char “;+” or “+;” are in the value of the 
parameter.


From the php point of view, using 
http://php.net/manual/en/function.urlencode.php , the 2 char “;+” or 
“+;” is valid in an urlencoded string.



Here are 2 tests URL and the dumped value from lua:
/dump_headers.php?p1=value1=word1+;word2=test
[info] 341/090330 (130491) : ua=word1+
The dumped value should be : word1+;word2

/dump_headers.php?p1=value1=word1;+word2=test
[info] 341/090951 (130491) : ua=word1
The dumped value should be : word1;+word2

Here is the haproxy config file (I removed everything not related to 
my question) :

global
debug
# lua file
lua-load url.lua

defaults
modehttp

frontend fe
bind :80
acl testurl url_beg /dump_headers.php
http-request lua.logValue if testurl
use_backend beok

backend beok
server mysrv 127.0.0.1:8080 check inter 1000ms fall 3 rise 1 
weight 100



Here is the lua file :
core.register_action("logValue", {"http-req"}, function(txn)
local var = txn.f:urlp("ua");
core.Info("ua=" .. var);
end)



haproxy -vv
HA-Proxy version 1.6.2 2015/11/03
Copyright 2000-2015 Willy Tarreau 

Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
  OPTIONS = USE_ZLIB=1 USE_OPENSSL=1 USE_LUA=yes USE_DEVICEATLAS=1 
USE_PCRE=1


Default settings :
  maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 
200


Encrypted password support via crypt(3): yes
Built with zlib version : 1.2.3
Compression algorithms supported : identity("identity"), 
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")

Built with OpenSSL version : OpenSSL 1.0.2d 9 Jul 2015
Running on OpenSSL version : OpenSSL 1.0.2d 9 Jul 2015
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports prefer-server-ciphers : yes
Built with PCRE version : 7.8 2008-09-05
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Built with Lua version : Lua 5.3.1
Built with transparent proxy support using: IP_TRANSPARENT 
IPV6_TRANSPARENT IP_FREEBIND


Available polling systems :
  epoll : pref=300,  test result OK
   poll : pref=200,  test result OK
 select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Running on centos 6.
I notice the same thing with haproxy 1.6.1 and lua 5.3.1 or 5.3.0

Note : in the frontend, if I use : http-request set-header 
X-debugua %[urlp(ua)]

I get the same value as I get from Lua.


Can you tell me if I do something the wrong way or if it is a bug or 
if it is intended ?


Best regards
Laurent

Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

[Dave Zhu (yanbzhu)]

Hey Willy,

On 12/8/15, 5:27 PM, "Willy Tarreau"  wrote:
>
>In my opinion, these suffixes should be used only after the real cert
>file name. So when you load "foobar.ecdsa", you should only consider
>"foobar.ecdsa.ocsp" and so on. And from what I remember, on the CLI
>we mention the cert name when feeding an OCSP entry so that should
>continue to work perfectly.

I agree, the limitation here is that the way HAProxy is current designed
only allows for 1 OCSP staple per SSL_CTX. This will have to change to
multiple staples for SSL_CTX¹s with multiple certs.
>
>I do think so. We'll just have to remerge 4, 5 and 6 into their respective
>patches (2 apparently) and we're good to go. If Emeric doesn't raise any
>objection (apparently you addressed his concerns) I can merge all that
>myself.
>If you prefer to remerge the patches above yourself, no problem for me.

I can remerge everything into 3 patches, it will be cleaner that way. I¹ll
send them out tomorrow.

Thanks!
-Dave

HAproxy between database and application

[Pavithra Kumar]

Hi ,
I am trying to load balance my database for high availability  . I am able
to configure  my database server as active-passive .but i am unable to
configure  my application to haproxy and then to my database .

Regards
Pavithra

Re: HAproxy between database and application

[Jessie P]

What does "unable" means, Wht issues are you facing? Config file ?

On Tuesday, December 8, 2015, Pavithra Kumar 
wrote:

> Hi ,
> I am trying to load balance my database for high availability  . I am able
> to configure  my database server as active-passive .but i am unable to
> configure  my application to haproxy and then to my database .
>
> Regards
> Pavithra
>

国外采购总监对下属的要求：重视网站发的E-mail畔淠谌荩

[WE60]

您好！

我司软件是一款专门帮助企业开发全球客户的外贸软件，集成了全球200个国家下800个搜索引擎，
自动从搜索引擎上收集目标客户的邮箱地址，并一对一发送开发信，帮助每天联系上万的目标客户，快速成订单！

特点：
1、客户搜索不设关键词限制，全球200多个国家的区域性800多个搜索引擎，9重信息过滤功能，为您的客户客户信息搜索在质与量上保驾护航，每天可获取【上万】客户信息


2、内置邮件营销模块，可多账号、多主题、多模板、避免邮件被服务器归类为垃圾邮件，有效提高邮件的到达率，每天可发送【上万】邮件


3、一对一专属客服为您软件的使用提供充分的保障，负责指导、培训以及长期跟踪客户使用软件，确保软件使用效果。

Now 您可以提供您的关键词，双*喜软件客服给您看功能效果  
 28--38--481319  这是 QQ 号码

Re: urlp strange behaviour ?

[thierry . fournier]

On Tue, 8 Dec 2015 20:52:45 +
Laurent Penot  wrote:

> Thx for your answer Thierry.
> 
> If you try with the URI : 
> /dump_headers.php?p1=value1=word1;word2;word3=test
> 
> Urlp called in haproxy configuration will return : “word1” which corresponds 
> to your answer.
> But if you use urlp from lua, it will return you the correct value, see my 
> dump :
> [info] 341/214152 (2580) : ua=word1;word2;word3
> 
> The difference of answer between theses 2 urlp call looks strange from my 
> side.
> As far as I know, a parameter value starts after the “=“ and ends either at 
> the first “&” encoutered or at the end of the URI.
> 
> So using urlp from lua, I thing there is only something wrong when there is 
> “;+” or “+;” in the value of the parameter.
> Using urlp from haproxy should have the same behaviour as using urlp from lua.
> 
> Does that make sense ? Or I’m really mistaken ?


Its a good question. I will see this ASAP because I'm curious. In
facts, the "txn.f:urlp()" is a wrapper on the "urlp" fucntion used
in the HAProxy config file.

Two differents behaviour hides probably a bug.

I just tested, and I reproduce the same behaviour in both cases.

Juste for information, the special compilation flag
"DEBUG=-DDEBUG_EXPR", enables a debug tools whih dump on screen some
contents:

   http-request set-var(sess.a) urlp(ua),debug

The previous line affect the content of the urlp to a variable (it is
useles), and the keyword "debug" dumps the result of "urlp(ua)" on
screen.

The Lua is your code. The result is:

   [debug converter] type: str 
   [info] 341/224620 (8053) : ua=word1

So, the same response for both cases. I try with:

   QS: ?p1=value1=word1;word2;word3=test

   [debug converter] type: str 
   [info] 341/224620 (8053) : ua=word1

   QS: ?p1=value1=word1;+word2=test

   [debug converter] type: str 
   [info] 341/225213 (8080) : ua=word1

   QS: ?p1=value1=word1+;word2=test

   [debug converter] type: str 
   [info] 341/225421 (8080) : ua=word1+

In all cases, there are the expected results and the same results.

I agree with a previous email "+;" and ";+" are valid url encoding.

Do I forgot or missed something ?

Thierry 


> 
> Best
> Laurent
> 
> 
> 
> 
> 
> 
> 
> On 08/12/15 11:23, "Thierry FOURNIER"  wrote:
> 
> >Hi,
> >
> >I agree with you, but in HAProxy, the ';' is considered as parameter
> >delimiter. Its hardcoded, and I don't known the reason.
> >
> >So the behaviour that you observe is the normal HAProxy behaviour.
> >
> >Thierry
> >
> >
> >
> >On Tue, 8 Dec 2015 09:17:38 +
> >Laurent Penot  wrote:
> >
> >> HI,
> >> 
> >> I received URL from which i need to extract several parameters, I do that 
> >> using urlp in lua. Values of parameters are urlencoded.
> >> And I notice something strange : urlp seems to get only the first part of 
> >> the value when the 2 char “;+” or “+;” are in the value of the parameter.
> >> 
> >> From the php point of view, using 
> >> http://php.net/manual/en/function.urlencode.php , the 2 char “;+” or “+;” 
> >> is valid in an urlencoded string.
> >> 
> >> 
> >> Here are 2 tests URL and the dumped value from lua:
> >> /dump_headers.php?p1=value1=word1+;word2=test
> >> [info] 341/090330 (130491) : ua=word1+
> >> The dumped value should be : word1+;word2
> >> 
> >> /dump_headers.php?p1=value1=word1;+word2=test
> >> [info] 341/090951 (130491) : ua=word1
> >> The dumped value should be : word1;+word2
> >> 
> >> Here is the haproxy config file (I removed everything not related to my 
> >> question) :
> >> global
> >> debug
> >> # lua file
> >> lua-load url.lua
> >> 
> >> defaults
> >> modehttp
> >> 
> >> frontend fe
> >> bind :80
> >> acl testurl url_beg /dump_headers.php
> >> http-request lua.logValue if testurl
> >> use_backend beok
> >> 
> >> backend beok
> >> server mysrv 127.0.0.1:8080 check inter 1000ms fall 3 rise 1 weight 100
> >> 
> >> 
> >> Here is the lua file :
> >> core.register_action("logValue", {"http-req"}, function(txn)
> >> local var = txn.f:urlp("ua");
> >> core.Info("ua=" .. var);
> >> end)
> >> 
> >> 
> >> 
> >> haproxy -vv
> >> HA-Proxy version 1.6.2 2015/11/03
> >> Copyright 2000-2015 Willy Tarreau 
> >> 
> >> Build options :
> >>   TARGET  = linux2628
> >>   CPU = generic
> >>   CC  = gcc
> >>   CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
> >>   OPTIONS = USE_ZLIB=1 USE_OPENSSL=1 USE_LUA=yes USE_DEVICEATLAS=1 
> >> USE_PCRE=1
> >> 
> >> Default settings :
> >>   maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
> >> 
> >> Encrypted password support via crypt(3): yes
> >> Built with zlib version : 1.2.3
> >> Compression algorithms supported : identity("identity"), 
> >> deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
> >> Built with OpenSSL version : OpenSSL 1.0.2d 9 Jul 2015
> >> Running on OpenSSL version : OpenSSL 

Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

[Dave Zhu (yanbzhu)]

Hey Bryan,

Now, about using the crt bind option with a directory of certs
https://cbonte.github.io/haproxy-dconv/configuration-1.6.html#crt (Bind options)

How should that work, especially if there are .ocsp and .issuer data in the crt 
directory? Currently, the ECDSA certificate seems to always be used even for 
non-ECC capable clients but I suspect that's due to the .ecdsa cert being 
loaded first and your patches do not cover that use case yet.

In this case, it would work the same as it does today. So the .rsa cert and the 
.ecdsa cert would get loaded as separate certificates, and the ECDSA would get 
added to the SNI tree first due to alphabetical loading as you postulated.

There are also 2 issues here.


  1.  Loading certs from a directory doesn't process multiple certs at the same 
time. This I can fix with another patch to add that functionality
  2.  .issuer, .ocsp and .sctl only apply to a single cert, not multiple certs. 
This is tricker, since we'd have to load multiple OCSP responses for stapling 
in the case of multiple certs, which would mean that we would have to set the 
OCSP response based on which certificate is presented. I could look into this 
as well, since it shouldn't be impossible to do given current HAProxy 
infrastructure. However, I would prefer that the functionality as it is today 
makes it into the code base. Similar with SCTL, although I have zero experience 
in that matter and would need guidance.

I'll look into #1 and the ocsp portion of #2. I'll let you know when I have 
updates.

In the mean time, is the code and functionality as of today acceptable? Could 
the feature be merged as is, with features added in the future?

-Dave

From: Bryan Talbot >
Date: Tuesday, December 8, 2015 at 4:02 PM
To: Yanbo Zhu >
Cc: Bryan Talbot >, Willy 
Tarreau >, Olivier Doucet 
>, Emeric Brun 
>, Lukas Tribus 
>, Remi Gacogne 
>, Nenad Merdanovic 
>, 
"haproxy@formilux.org" 
>
Subject: Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

On Tue, Dec 8, 2015 at 11:18 AM, Dave Zhu (yanbzhu) 
> wrote:
Hey Bryan,

I believe I have gotten to the bottom of the behavior that you are seeing:


  1.  0.9.8 client cannot connect to dual cert port: This was a bug on my part. 
I neglected to set a DHE keys for the SSL_CTX with multiple certs. I've 
attached another set of patches (1-5 are identical, 6 is new) that fixes this.

yep, patch 6 fixes this problem for me.



  1.  ECC capable client does not use ECC cipher: I believe this is due to your 
test configuration. Openssl prefers RSA ciphers by default, and so if you don't 
specify an ECC cipher first, it will always pick an RSA cipher. Your test uses 
"./openssl-1.0.2e/apps/openssl s_client -connect 127.0.0.1:8443" as the 
command, which will use the default cipher list. Try specifying an ECC cipher 
as the first cipher and it should work.

Of course, I should have realized that too. I've updated the bind ciphers to 
prioritize ECDSA over RSA and that fixes the issue. So the basic tests I 
defined before are all passing now but only when the crt line specifies a "pem" 
file that doesn't exist and .ecdsa / .rsa files are loaded from that base.


Now, about using the crt bind option with a directory of certs
https://cbonte.github.io/haproxy-dconv/configuration-1.6.html#crt (Bind options)

How should that work, especially if there are .ocsp and .issuer data in the crt 
directory? Currently, the ECDSA certificate seems to always be used even for 
non-ECC capable clients but I suspect that's due to the .ecdsa cert being 
loaded first and your patches do not cover that use case yet.



-Bryan

[PATCH]: CLEANUP

[David CARLIER]

Hi all.

Just a small cleanup patch.

Cheers.


0001-CLEANUP-haproxy-using-_GNU_SOURCE-instead-of-__USE_G.patch
Description: Binary data