Flight case solution for Kiosk display or Smart TV
Hi there, We are the leading flight case manufacturer especially for Kiosk display/Smart TV products. We have various solutions for the packaging of your fragile display proudcts for transportation. They can be with hidden wheels or removable wheels, also they can afford the weight up to 150kg. If you have interest to work with us to design new packaging for your products, please let me know by return. Best Regards Ellen Arboocase China Tel:+86-18676370706
Re: HTTP Response Rewriting to Replace Internal IP with FQDN
On Wed, Oct 7, 2015 at 7:06 AM, Susheel Jalali
wrote:
> Dear HAProxy Developers,
>
> After incorporating insights from Bryan Talbot and articles from Baptiste
> Assman on HAProxy Web site, we have been able to get the basic
> configuration of HAProxy going. Now we are adding configuration to access
> specific products in our LAN.
>
> We would like to access Product1 via URL:
> https://coscend.com:14443/Product1/
>
> Output URL from the Product1 server should be:
> https://coscend.com:14443/Product1/signin?xyz
>
> What we are getting: https://Internal_IP:14443/Product1/signin?xyz
>
> The server presents the right page, but with internal IP address of the
> server. Hence, the product can only be accessed from internal LAN, not
> from WAN. What are we missing?
>
> Below is the configuration deployed.
>
> global
>
> […]
>
> default
>
> […]
>
>
>
> frontend webapps-frontend
>
> bind *:80 name http
>
> bind *:443 name https ssl crt /path/to/server.pem
>
>
>
> log global
>
> optionforwardfor
>
> optionhttplog clf
>
>
>
> reqadd X-Forwarded-Proto:\ https if { ssl_fc }
>
> reqadd X-Forwarded-Proto:\ http if !{ ssl_fc }
>
> #http-request add-header X-Forwarded-Proto:\ https if { ssl_fc } #
> Don't know how to use it instead of reqadd
>
> #http-request add-header X-Forwarded-Proto:\ http if !{ ssl_fc } #
> Don't know how to use it instead of reqadd
>
>
>
> acl host_httpsreq.hdr(Host) coscend.com:14443 # 14443 is due to
> port forwarding deployment
>
> acl path_subdomain_p1 path_beg -i /Product1
>
>
>
> use_backend subdomain_p1-backend if host_https path_subdomain_p1
>
>
>
> backend subdomain_p1-backend
>
> http-request set-header Host
>
> reqirep ^([^\ ]*)\ /Product1/?([^\ ]*)\ (.*)$ \1\ /Product1\2\ \3
>
>
>
> acl hdr_location res.hdr(Location) -m found
>
> #http-response replace-header Host (.*) %%HP if hdr_location # This
> is not working
>
> rspirep ^(Location:)\ (https?://([^/]*))/(.*)$\1\
> http://\3/Product1/\4 if hdr_location
>
What happens if you move these two from the backend into the frontend
section (I believe that's where they belong):
acl hdr_location res.hdr(Location) -m found
rspirep ^(Location:)\ (https?://([^/]*))/(.*)$\1\
http://\3/Product1/\4 if hdr_location
Also in the rspirep you are rewriting https to http but you say the
response you are seeing is still with https:
https://Internal_IP:14443/Product1/signin?xyz
which most probably means that condition is not working for sure.
In case you are serving a single domain maybe simplifying this to begin
with may help:
rspirep ^(Location:)\ https?://[^/]*/(.*)$\1\
http://coscend.com/Product1/\2 if hdr_location
Also any messages during haproxy startup or in the haproxy log indicating
possible issues? Something along the lines of "this and this statement will
never match due to bla bla".
>
>
> server Product1.VM0 cookie c check
>
>
>
> Thank you.
>
> --
>
> Sincerely,
>
> Susheel Jalali
>
> Coscend Communications Solutions
>
> Elite Premio Complex Suite 200, Pune 411045 Maharashtra India
> susheel.jal...@coscend.com
>
> Web site: www.Coscend.com
> --
>
> CONFIDENTIALITY NOTICE: See 'Confidentiality Notice Regarding E-mail
> Messages from Coscend Communications Solutions' posted at:
> http://www.Coscend.com/Terms_and_Conditions.html
>
>
--
Igor Cicimov | DevOps
p. +61 (0) 433 078 728
e. ig...@encompasscorporation.com
Re: core dump, lua service, 1.6-dev6 ss-20150930
Hi Thierry,
Op 6-10-2015 om 9:47 schreef Thierry FOURNIER:
On Mon, 5 Oct 2015 21:04:08 +0200
PiBa-NL wrote:
Hi Thierry,
Hi Pieter,
With or without "option http-server-close" does not seem to make any
difference.
Sure, it is only an answer to the Cyril keep alive problem. I encounter
again the keepalive problem :(
The HAProxy applet (services) can't directly uses the keepalive. The
service send its response with an "internal" connection: close. If you
activate the debug, you will see the header "connection: close".
You must configure HAProxy to use keepalive between the frontend and
the client.
Ok. whell without further specific configuration it is keeping
connections alive, but as that is the default thats ok.
Adding a empty backend does seem to resolve the problem, stats also show
the backend handling connections and tracking its 2xx http result
session totals when configured like this.:
frontend http_frt
mode http
bind :801
http-request use-service lua.hello-world
default_backend http-lua-service
backend http-lua-service
mode http
I can't reproduce the problem with the last dev version. But, I
regognize the backtrace, I already encounter the same. I'm believe that
is fixed in the dev6 :(
Using dev7 i can still reproduce it..
I try to bench with my http injector, and I try with ab with and
without keep alive. I try also to stress the admin page, and I can't
reproduce pthe problem.
Argg, I see a major difference: to use freebsd. I don't have the
environment for testing it. I must install a VM.
Op 5-10-2015 om 16:06 schreef Thierry FOURNIER:
Hi,
I process this email later. For waiting, I propose to you to set the
"option http-server-close". Actually, the "services" doesn't support
itself the keepalive, but HAProxy does this job.
The "option http-server-close" expectes a server-close from the service
stream. The front of HAProxy maintains the keep-alive between the
client and the haproxy.
This method embbed a limitation: if some servers are declared in the
backend, the "option http-server-close" forbid the keepalive between
haproxy and the serveur.
Can you test with this option ?
Thierry
On Thu, 1 Oct 2015 23:00:45 +0200
Cyril Bonté wrote:
Hi,
Le 01/10/2015 20:52, PiBa-NL a écrit :
Hi List,
With the config below while running 'siege' i get a core dump within a
few hundreds of requests.. Viewing the stats page from a chrome browser
while siege is running seems to crash it sooner..
Is below enough to find the cause? Anything else i should try?
This is embarrassing because with your configuration, I currently can't
reproduce a segfault but I can reproduce another issue with HTTP
keep-alive requests !
(details below)
Using the haproxy snapshot from: 1.6-dev6 ss-20150930
Or perhaps i just did compile it wrong?..
make NO_CHECKSUM=yes clean debug=1 reinstall WITH_DEBUG=yes
global
stats socket /tmp/hap.socket level admin
maxconn 6
lua-load /haproxy/brute/hello.lua
defaults
timeout client 1
timeout connect 1
timeout server 1
frontend HAProxyLocalStats
bind :2300 name localstats
mode http
stats enable
stats refresh 1000
stats admin if TRUE
stats uri /
frontend http_frt
bind :801
mode http
http-request use-service lua.hello-world
Here, if I use :
$ ab -n100 -c1 -k http://127.0.0.1:801/
There will be a 1ms delay after the first request.
Or with another test case :
echo -ne "GET / HTTP/1.1\r\nHost: localhost\r\n\r\nGET /
HTTP/1.1\r\nHost: localhost\r\n\r\n"| nc localhost 801
HTTP/1.1 200 OK
content-type: text/plain
Transfer-encoding: chunked
d
Hello World !
0
=> only 1 response
Now, if I change "frontend http_frt" to "listen http_frt", I get the
awaited behaviour.
The second test case with "listen" :
echo -ne "GET / HTTP/1.1\r\nHost: localhost\r\n\r\nGET /
HTTP/1.1\r\nHost: localhost\r\n\r\n"| nc localhost 801
HTTP/1.1 200 OK
content-type: text/plain
Transfer-encoding: chunked
d
Hello World !
0
HTTP/1.1 200 OK
content-type: text/plain
Transfer-encoding: chunked
d
Hello World !
0
=> the 2 responses are returned
core.register_service("hello-world", "http", function(applet)
local response = "Hello World !"
applet:set_status(200)
applet:add_header("content-type", "text/plain")
applet:start_response()
applet:send(response)
end )
(gdb) bt full
#0 0x000801a2da75 in memcpy () from /lib/libc.so.7
No symbol table info available.
#1 0x00417388 in buffer_slow_realign (buf=0x7d3c90) at
src/buffer.c:166
block1 = -3306
block2 = 0
#2 0x00480c42 in http_wait_for_request (s=0x80247d600,
req=0x80247d610, an_bit=4)
at src/proto_http.c:2686
cur_idx = -6336
sess = (struct session *) 0x80241e400
txn = (struct http_txn *) 0x802bb2140
msg = (struct http_msg *) 0x802bb21a0
ctx = {line = 0x2711079 , idx
= 3, val = 0
Set/add header
Hello,
We have Ngnix proxy backend server proxying request for zimbra.
We have haproxy servers above the Ngnix proxies.
Due some code within zimbra, zimbra is unable to accept set header/ add header
from haproxy, so thinking of removing, could you elaborate on how this below
line works with example.
http-request set-header X-Forwarded-Port %[dst_port]
http-request add-header X-Forwarded-Proto https if { ssl_fc }
RE: OPTIM : IPv6 literal address parsing
Thanks for your feedback. I think it need improvement as I currently replace the closing bracket with a null directly in the string. Working on a copy and leave the original string as-is should be better. Plus adding some logic here and there to match all cases ... I’ll work on this asap. Mildis Le 2015-10-06 19:39, Lukas Tribus a écrit : Hi Mildis, And regarding "2001:db8::1234", you can't forbit it simply because you don't know if 1234 is a port or not in this context, as you have reported. Sure. In this very specific case 1234 can’t be a port as 2001:db8:: is then a subnet. For the record: you can't know that, unless you know the subnetmask. I can assign 2001:db8::/128 to a loopback and bind a service to it, I can bind 2001:db8::/127 to one box and connect it to a box with 2001:db8::1/127 on the other side. I can also configure 2001:db8::/16 on box on my private network, where 2001:: is the subnet IP, not 2001:db8::. A lot of valid configurations out there, you can't assume that all configurations are simple and straightforward unicast LAN networks. It is then the kernels job to reject binds to adresses it considers invalid (for example due to subnetting), but the application does not (and imho *must not*) be subnet aware. Regarding the patch: I think this is very useful and I like the square brackets very much. I'm always scratching my head when I see a ipv6 bind configuration in haproxy and the square brackets fix this interpretation problem once and for all (for users that want to use them, others just keep using current notation). Thanks for this! Regards, Lukas
HTTP Response Rewriting to Replace Internal IP with FQDN
Dear HAProxy Developers,
After incorporating insights from Bryan Talbot and articles from
Baptiste Assman on HAProxy Web site, we have been able to get the basic
configuration of HAProxy going. Now we are adding configuration to
access specific products in our LAN.
We would like to access Product1 via URL:
https://coscend.com:14443/Product1/
Output URL from the Product1 server should be:
https://coscend.com:14443/Product1/signin?xyz
What we are getting: https://Internal_IP:14443/Product1/signin?xyz
The server presents the right page, but with internal IP address of the
server. Hence, the product can only be accessed from internal LAN, not
from WAN. What are we missing?
Below is the configuration deployed.
global
[…]
default
[…]
frontend webapps-frontend
bind *:80 name http
bind *:443 name https ssl crt /path/to/server.pem
log global
optionforwardfor
option httplog clf
reqadd X-Forwarded-Proto:\ https if { ssl_fc }
reqadd X-Forwarded-Proto:\ http if !{ ssl_fc }
#http-request add-header X-Forwarded-Proto:\ https if { ssl_fc }
# Don't know how to use it instead of reqadd
#http-request add-header X-Forwarded-Proto:\ http if !{ ssl_fc } #
Don't know how to use it instead of reqadd
acl host_httpsreq.hdr(Host) coscend.com:14443 # 14443 is due to
port forwarding deployment
acl path_subdomain_p1 path_beg -i /Product1
use_backend subdomain_p1-backend if host_https path_subdomain_p1
backend subdomain_p1-backend
http-request set-header Host
reqirep ^([^\ ]*)\ /Product1/?([^\ ]*)\ (.*)$ \1\ /Product1\2\ \3
acl hdr_location res.hdr(Location) -m found
#http-response replace-header Host (.*) %%HP if hdr_location # This is
not working
rspirep ^(Location:)\ (https?://([^/]*))/(.*)$\1\
http://\3/Product1/\4 if hdr_location
server Product1.VM0 cookie c check
Thank you.
--
Sincerely,
Susheel Jalali
Coscend Communications Solutions
Elite Premio Complex Suite 200, Pune 411045 Maharashtra India
susheel.jal...@coscend.com
Web site: www.Coscend.com
--
CONFIDENTIALITY NOTICE: See 'Confidentiality Notice Regarding E-mail
Messages from Coscend Communications Solutions' posted at:
http://www.Coscend.com/Terms_and_Conditions.html
RE: OPTIM : IPv6 literal address parsing
Hi Mildis, >> And regarding "2001:db8::1234", you can't forbit it simply because you >> don't know if 1234 is a port or not in this context, as you have >> reported. > > Sure. In this very specific case 1234 can’t be a port as 2001:db8:: is > then a subnet. For the record: you can't know that, unless you know the subnetmask. I can assign 2001:db8::/128 to a loopback and bind a service to it, I can bind 2001:db8::/127 to one box and connect it to a box with 2001:db8::1/127 on the other side. I can also configure 2001:db8::/16 on box on my private network, where 2001:: is the subnet IP, not 2001:db8::. A lot of valid configurations out there, you can't assume that all configurations are simple and straightforward unicast LAN networks. It is then the kernels job to reject binds to adresses it considers invalid (for example due to subnetting), but the application does not (and imho *must not*) be subnet aware. Regarding the patch: I think this is very useful and I like the square brackets very much. I'm always scratching my head when I see a ipv6 bind configuration in haproxy and the square brackets fix this interpretation problem once and for all (for users that want to use them, others just keep using current notation). Thanks for this! Regards, Lukas
Re: OPTIM : IPv6 literal address parsing
On Tue, Oct 06, 2015 at 05:57:09PM +0200, Mildis wrote: > >And regarding "2001:db8::1234", you can't forbit it simply because you > >don't know if 1234 is a port or not in this context, as you have > >reported. > > Sure. In this very specific case 1234 can???t be a port as 2001:db8:: is > then a subnet. > Is a subnet a valid entry in this context ? It must not be our problem. The address parser is used to parse addresses. If someone finds a good use for a subnet, we'd rather not have to re-change the parser just because at one point we decided to make it too restrictive. Thanks, Willy
Re: OPTIM : IPv6 literal address parsing
Le 2015-10-06 17:47, Willy Tarreau a écrit : Hi, You must not forbid "[2001:db8::1234]:" otherwise people will not adopt the square brackets notation. Some of them probably already do things like this : server srv1 $IP_SRV1:$PORT_SRV1 And fill the respective environment variables with either IPv4 or IPv6. By preventing a clearly non-ambigous config from being parsed, you'll simply make them stay away from this new syntax, which is the opposite to what you're seeking. Got it. And regarding "2001:db8::1234", you can't forbit it simply because you don't know if 1234 is a port or not in this context, as you have reported. Sure. In this very specific case 1234 can’t be a port as 2001:db8:: is then a subnet. Is a subnet a valid entry in this context ? Otherwise it's OK for me. Don’t forget to update the doc accordingly! I will. Mildis
Re: OPTIM : IPv6 literal address parsing
Hi, On Tue, Oct 06, 2015 at 05:34:07PM +0200, Mildis wrote: > Hi Willy, > > My bad : in the doc, I didn???t get the « add a colon without a port to > end an address » trick. > That???s why I was lost at first. > The doc obviously says ???[:[port]]??? making the port optional > and an ending colon valid but it looks like a typo to me as ending an IPv6 > address with a colon is not one of my habit. > > The provided patch sent initially should handle square brackets but > still makes the colon mandatory even with no port. > I???ll rework it so it accepts : > - 2001:db8::1234: as IPv6 no port (for backward compatibility) > - [2001:db8::1234] as IPv6 no port > - [2001:db8::1234]:80 as IPv6 with port > but forbid ???[2001:db8::1234]:??? and ???2001:db8::1234??? You must not forbid "[2001:db8::1234]:" otherwise people will not adopt the square brackets notation. Some of them probably already do things like this : server srv1 $IP_SRV1:$PORT_SRV1 And fill the respective environment variables with either IPv4 or IPv6. By preventing a clearly non-ambigous config from being parsed, you'll simply make them stay away from this new syntax, which is the opposite to what you're seeking. And regarding "2001:db8::1234", you can't forbit it simply because you don't know if 1234 is a port or not in this context, as you have reported. Otherwise it's OK for me. Don't forget to update the doc accordingly! Willy
Re: OPTIM : IPv6 literal address parsing
Hi Willy, My bad : in the doc, I didn’t get the « add a colon without a port to end an address » trick. That’s why I was lost at first. The doc obviously says ‘[:[port]]’ making the port optional and an ending colon valid but it looks like a typo to me as ending an IPv6 address with a colon is not one of my habit. The provided patch sent initially should handle square brackets but still makes the colon mandatory even with no port. I’ll rework it so it accepts : - 2001:db8::1234: as IPv6 no port (for backward compatibility) - [2001:db8::1234] as IPv6 no port - [2001:db8::1234]:80 as IPv6 with port but forbid ‘[2001:db8::1234]:’ and ‘2001:db8::1234’ Would it makes sense to you ? mildis Le 2015-10-06 11:11, Willy Tarreau a écrit : On Mon, Oct 05, 2015 at 06:42:52PM +0200, Mildis wrote: Le 2015-10-05 18:07, David du Colombier a écrit : >>It looks like IPv6 parsing may lead to errors. >>The logic cannot distinguish from ???2001:db8::1234:80??? as : >>- a plain IPv6 address 2001:db8::1234:80 >>- IPv6 2001:db8::1234 on port 80 > >As far I remember, to prevent this confusion, we made the final >colon mandatory on IPv6 addresses. This way, anything before >the final colon is the address. > >If you don't want to specify the port explicitly, the address >ends with a colon. Technically, it???s seem OK. But it should be less haproxy-centric to stick to an RFC. We support all the formats mandated by RFCs 1884, 2373, 3513, and 4291. The address format doesn't mandate the use of a port which is a transport-layer issue. Many (most) products have historically supported : to group layer 3 and layer 4 information in a same word. And haproxy is no exception and has supported this for 15 years in all places where an address was expected since the port was almost always there. Thus when introducing IPv6, it was natural that only the address part had to be distinguished between IPv4 and IPv6. At some point we added the ability to support port-less addresses at certain places (eg: server addresses). In order to leverage the ambiguity it could raise, these ones had the trailing colon mandatory. We could also decide to add support for brackets in the address parser so that it's possible to write [address]:port like in URLs, I'm fine with this, though I'm not the one who will spend time on this right now. And by the way I think that the format is perfectly clear in the documentation. Regards, Willy
Re: [PATCH 1/1] MINOR: cli: Dump all resolvers stats if no resolver
Thanks! On Tue, Oct 6, 2015 at 12:08 AM, Willy Tarreau wrote: > On Mon, Oct 05, 2015 at 11:57:08PM +0200, Baptiste wrote: >> Andrew, >> >> My appologies about the proxy_find_by_name function, I was not in the >> right context!!! >> Tested and approved. >> >> Willy, you can apply :) >> >> Thanks a lot for your contribution, Andrew. > > Applied, thanks guys! > > Willy > -- - Andrew Hayworth
Re: Interactive stats socket broken on master
On Fri, Oct 2, 2015 at 10:24 AM, Andrew Hayworth wrote:> > Attached is a patch that fixes the issue for me. Willy, any thoughts on merging this patch into 1.6?
[PATCH] MINOR: lua: fix a spelling error in some error messages
From: Vincent Bernat "unknown" was spelled "unkown". --- src/hlua.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/hlua.c b/src/hlua.c index ae3fe8938f6b..c797d4011129 100644 --- a/src/hlua.c +++ b/src/hlua.c @@ -1261,7 +1261,7 @@ __LJMP static int hlua_del_acl(lua_State *L) ref = pat_ref_lookup(name); if (!ref) - WILL_LJMP(luaL_error(L, "'del_acl': unkown acl file '%s'", name)); + WILL_LJMP(luaL_error(L, "'del_acl': unknown acl file '%s'", name)); pat_ref_delete(ref, key); return 0; @@ -1283,7 +1283,7 @@ static int hlua_del_map(lua_State *L) ref = pat_ref_lookup(name); if (!ref) - WILL_LJMP(luaL_error(L, "'del_map': unkown acl file '%s'", name)); + WILL_LJMP(luaL_error(L, "'del_map': unknown acl file '%s'", name)); pat_ref_delete(ref, key); return 0; @@ -1305,7 +1305,7 @@ static int hlua_add_acl(lua_State *L) ref = pat_ref_lookup(name); if (!ref) - WILL_LJMP(luaL_error(L, "'add_acl': unkown acl file '%s'", name)); + WILL_LJMP(luaL_error(L, "'add_acl': unknown acl file '%s'", name)); if (pat_ref_find_elt(ref, key) == NULL) pat_ref_add(ref, key, NULL, NULL); @@ -1331,7 +1331,7 @@ static int hlua_set_map(lua_State *L) ref = pat_ref_lookup(name); if (!ref) - WILL_LJMP(luaL_error(L, "'set_map': unkown map file '%s'", name)); + WILL_LJMP(luaL_error(L, "'set_map': unknown map file '%s'", name)); if (pat_ref_find_elt(ref, key) != NULL) pat_ref_set(ref, key, value, NULL); -- 2.6.1
FW: HAProxy
Bonjour First of all, if I need to explain in English, please tell me. Je suis bloqué avec HAProxy sur une VM. J'ai un serveur Debian 8.2 avec HAProxy 1.5.14. Et "derrière", j'ai 2 serveurs Windows avec IIS 8.5 & SharePoint 2013. Cela fonctionne bien en HTTP, mais pas en HTTPS. avec HTTPS j'ai soit des erreurs 503 & 504 en altérnance. Si quelqu'un à une idée ca serait cool. Voilà ma config global log /dev/loglocal0 log /dev/loglocal1 notice chroot /var/lib/haproxy stats socket /run/haproxy/admin.sock mode 660 level admin stats timeout 30s user haproxy group haproxy daemon maxconn 2048 tune.ssl.default-dh-param 2048 ca-base /etc/ssl/certs crt-base /etc/ssl/private ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS ssl-default-bind-options no-sslv3 defaults log global modehttp option forwardfor option http-server-close option httplog option dontlognull timeout connect 5000 timeout client 5 timeout server 5 frontend www-http bind *:80 default_backend www-backend frontend www-https bind *:443 ssl crt ./monfichier.pem default_backend www-backend-https backend www-backend server www-1 192.168.1.2:80 check server www-2 192.168.1.3:80 check backend www-backend-https server www-1 192.168.1.2:443 check server www-2 192.168.1.3:443 check Cédric Petter cedric.pet...@bpa-solutions.net
Re: [ANNOUNCE] haproxy-1.6-dev7
On 06/10/2015 12:25 μμ, Willy Tarreau wrote: > Hi ladies and gentlemen! > > Things are calming down when I'm away from the keyboard, I'll start to > think I'm really the only one who introduces bugs! > > Some issues were fixed since dev6 : > - segfault recent regression in logs from lua > - getaddrinfo() didn't honnor local address selection policy on FreeBSD > - load-server-state could possibly crash the process upon reload > - the new silent-drop action sometimes failed to properly send a TCP RST. > - external checks didn't check the correct argument in the config > > Overall, we got some nice doc fixes proving that people actually read > them, I really thank everyone involved! > > I'm issuing dev7 to make tests easier and almost riskless (at least regarding > the reported bugs). > > Pushed to some servers. Thanks for the release. Waiting for 1.6.0:-), Pavlos signature.asc Description: OpenPGP digital signature
[ANNOUNCE] haproxy-1.6-dev7
Hi ladies and gentlemen! Things are calming down when I'm away from the keyboard, I'll start to think I'm really the only one who introduces bugs! Some issues were fixed since dev6 : - segfault recent regression in logs from lua - getaddrinfo() didn't honnor local address selection policy on FreeBSD - load-server-state could possibly crash the process upon reload - the new silent-drop action sometimes failed to properly send a TCP RST. - external checks didn't check the correct argument in the config Overall, we got some nice doc fixes proving that people actually read them, I really thank everyone involved! I'm issuing dev7 to make tests easier and almost riskless (at least regarding the reported bugs). There's a remaining issue regarding services written in Lua and keep-alive which can crash the process. I'm not that much worried by now, we just need to ensure this can be fixed without pushing something else into an unsafe corner. Here comes the changelog, it looks like the type of changelog I'm expecting on the last week before the release, so thanks for slowing down on changes. - MINOR: cli: Dump all resolvers stats if no resolver section is given - BUG: config: external-check command validation is checking for incorrect arguments. - DOC: documentation format cleanups - DOC: lua: few typos. - BUG/MEDIUM: str2ip: make getaddrinfo() consider local address selection policy - BUG/MEDIUM: logs: segfault writing to log from Lua - DOC: fix lua use-service example - MINOR: payload: add support for tls session ticket ext - MINOR: lua: remove the run flag - MEDIUM: lua: change the timeout execution - MINOR: lua: rename the tune.lua.applet-timeout - DOC: lua: update Lua doc - DOC: lua: update doc according with the last Lua changes - MINOR: http/tcp: fill the avalaible actions - DOC: reorder misplaced res.ssl_hello_type in the doc - BUG/MINOR: tcp: make silent-drop always force a TCP reset - CLEANUP: tcp: silent-drop: only drain the connection when quick-ack is disabled - BUILD: tcp: use IPPROTO_IP when SOL_IP is not available - BUILD: server: fix build warnings introduced by load-server-state - BUG/MEDIUM: server: fix misuse of format string in load-server-state's warnings Usual URLs below : Site index : http://www.haproxy.org/ Sources : http://www.haproxy.org/download/1.6/src/devel/ Git repository : http://git.haproxy.org/git/haproxy.git/ Git Web browsing : http://git.haproxy.org/?p=haproxy.git Changelog: http://www.haproxy.org/download/1.6/src/CHANGELOG Cyril's HTML doc : http://cbonte.github.com/haproxy-dconv/intro-1.6.html Cyril's HTML doc : http://cbonte.github.com/haproxy-dconv/configuration-1.6.html Regards, Willy
Re: OPTIM : IPv6 literal address parsing
On Mon, Oct 05, 2015 at 06:42:52PM +0200, Mildis wrote: > Le 2015-10-05 18:07, David du Colombier a écrit : > >>It looks like IPv6 parsing may lead to errors. > >>The logic cannot distinguish from ???2001:db8::1234:80??? as : > >>- a plain IPv6 address 2001:db8::1234:80 > >>- IPv6 2001:db8::1234 on port 80 > > > >As far I remember, to prevent this confusion, we made the final > >colon mandatory on IPv6 addresses. This way, anything before > >the final colon is the address. > > > >If you don't want to specify the port explicitly, the address > >ends with a colon. > > Technically, it???s seem OK. > But it should be less haproxy-centric to stick to an RFC. We support all the formats mandated by RFCs 1884, 2373, 3513, and 4291. The address format doesn't mandate the use of a port which is a transport-layer issue. Many (most) products have historically supported : to group layer 3 and layer 4 information in a same word. And haproxy is no exception and has supported this for 15 years in all places where an address was expected since the port was almost always there. Thus when introducing IPv6, it was natural that only the address part had to be distinguished between IPv4 and IPv6. At some point we added the ability to support port-less addresses at certain places (eg: server addresses). In order to leverage the ambiguity it could raise, these ones had the trailing colon mandatory. We could also decide to add support for brackets in the address parser so that it's possible to write [address]:port like in URLs, I'm fine with this, though I'm not the one who will spend time on this right now. And by the way I think that the format is perfectly clear in the documentation. Regards, Willy
Jusqu'a 80% de reduction sur vos cartouches!
Title: Imprim'Encre Si ce message ne s'affiche pas correctement, lisez-le sur cette page PROFITEZ DE NOTRE OFFRE SPéCIALE RENTREE Frais de port offert dès 49€ Livraison sur toute la France en 24H Garantie 2 ans sur nos cartouches Garantie Satisfait ou remboursé Vous recevez ce message à l'adresse haproxy@formilux.org Si cette offre ne vous interesse plus, vous pouvez désabonner automatiquement ici
Re: core dump, lua service, 1.6-dev6 ss-20150930
On Mon, 5 Oct 2015 21:04:08 +0200
PiBa-NL wrote:
> Hi Thierry,
Hi Pieter,
> With or without "option http-server-close" does not seem to make any
> difference.
Sure, it is only an answer to the Cyril keep alive problem. I encounter
again the keepalive problem :(
The HAProxy applet (services) can't directly uses the keepalive. The
service send its response with an "internal" connection: close. If you
activate the debug, you will see the header "connection: close".
You must configure HAProxy to use keepalive between the frontend and
the client.
> Adding a empty backend does seem to resolve the problem, stats also show
> the backend handling connections and tracking its 2xx http result
> session totals when configured like this.:
>
> frontend http_frt
>mode http
>bind :801
>http-request use-service lua.hello-world
>default_backend http-lua-service
> backend http-lua-service
>mode http
I can't reproduce the problem with the last dev version. But, I
regognize the backtrace, I already encounter the same. I'm believe that
is fixed in the dev6 :(
I try to bench with my http injector, and I try with ab with and
without keep alive. I try also to stress the admin page, and I can't
reproduce pthe problem.
Argg, I see a major difference: to use freebsd. I don't have the
environment for testing it. I must install a VM.
> Op 5-10-2015 om 16:06 schreef Thierry FOURNIER:
> > Hi,
> >
> > I process this email later. For waiting, I propose to you to set the
> > "option http-server-close". Actually, the "services" doesn't support
> > itself the keepalive, but HAProxy does this job.
> >
> > The "option http-server-close" expectes a server-close from the service
> > stream. The front of HAProxy maintains the keep-alive between the
> > client and the haproxy.
> >
> > This method embbed a limitation: if some servers are declared in the
> > backend, the "option http-server-close" forbid the keepalive between
> > haproxy and the serveur.
> >
> > Can you test with this option ?
> >
> > Thierry
> >
> >
> >
> > On Thu, 1 Oct 2015 23:00:45 +0200
> > Cyril Bonté wrote:
> >
> >> Hi,
> >>
> >> Le 01/10/2015 20:52, PiBa-NL a écrit :
> >>> Hi List,
> >>>
> >>> With the config below while running 'siege' i get a core dump within a
> >>> few hundreds of requests.. Viewing the stats page from a chrome browser
> >>> while siege is running seems to crash it sooner..
> >>>
> >>> Is below enough to find the cause? Anything else i should try?
> >> This is embarrassing because with your configuration, I currently can't
> >> reproduce a segfault but I can reproduce another issue with HTTP
> >> keep-alive requests !
> >>
> >> (details below)
> >>
> >>> Using the haproxy snapshot from: 1.6-dev6 ss-20150930
> >>> Or perhaps i just did compile it wrong?..
> >>> make NO_CHECKSUM=yes clean debug=1 reinstall WITH_DEBUG=yes
> >>>
> >>> global
> >>> stats socket /tmp/hap.socket level admin
> >>> maxconn 6
> >>> lua-load /haproxy/brute/hello.lua
> >>>
> >>> defaults
> >>> timeout client 1
> >>> timeout connect 1
> >>> timeout server 1
> >>>
> >>> frontend HAProxyLocalStats
> >>> bind :2300 name localstats
> >>> mode http
> >>> stats enable
> >>> stats refresh 1000
> >>> stats admin if TRUE
> >>> stats uri /
> >>> frontend http_frt
> >>> bind :801
> >>> mode http
> >>> http-request use-service lua.hello-world
> >> Here, if I use :
> >> $ ab -n100 -c1 -k http://127.0.0.1:801/
> >> There will be a 1ms delay after the first request.
> >>
> >> Or with another test case :
> >> echo -ne "GET / HTTP/1.1\r\nHost: localhost\r\n\r\nGET /
> >> HTTP/1.1\r\nHost: localhost\r\n\r\n"| nc localhost 801
> >> HTTP/1.1 200 OK
> >> content-type: text/plain
> >> Transfer-encoding: chunked
> >>
> >> d
> >> Hello World !
> >> 0
> >>
> >> => only 1 response
> >>
> >> Now, if I change "frontend http_frt" to "listen http_frt", I get the
> >> awaited behaviour.
> >>
> >> The second test case with "listen" :
> >> echo -ne "GET / HTTP/1.1\r\nHost: localhost\r\n\r\nGET /
> >> HTTP/1.1\r\nHost: localhost\r\n\r\n"| nc localhost 801
> >> HTTP/1.1 200 OK
> >> content-type: text/plain
> >> Transfer-encoding: chunked
> >>
> >> d
> >> Hello World !
> >> 0
> >>
> >> HTTP/1.1 200 OK
> >> content-type: text/plain
> >> Transfer-encoding: chunked
> >>
> >> d
> >> Hello World !
> >> 0
> >>
> >> => the 2 responses are returned
> >>
> >>> core.register_service("hello-world", "http", function(applet)
> >>> local response = "Hello World !"
> >>> applet:set_status(200)
> >>> applet:add_header("content-type", "text/plain")
> >>> applet:start_response()
> >>> applet:send(response)
> >>> end )
> >>>
> >>> (gdb) bt full
> >>> #0 0x000801a2da75 in memcpy () from /lib/libc.so.7
> >>> No symbol table info available.
> >>> #1 0x00417388 in buffer_slow_realign (buf=0x7d3c90) at
> >>> src/buffer.c:166
> >>> block1 = -3306
> >>>
