RE: Upcoming haproxy build fixes for Cygwin & AIX
Wow. Really appreciate you following up. Thanks Willy! Patrick Overbey Fiserv -Original Message- From: Willy Tarreau [mailto:w...@1wt.eu] Sent: Friday, March 29, 2019 4:01 PM To: maio...@gmail.com; Overbey, Patrick (Sioux Falls) Cc: haproxy@formilux.org Subject: Upcoming haproxy build fixes for Cygwin & AIX ⚠ EXTERNAL MESSAGE – Think Before You Click Hi, I finally could figure how to work around the issues with very old linkers. I could work on this using a very old AIX machine we have here running AIX 5.1, so now that my test code works on it, I'm fairly confident more recent versions will as well, and given that Jeffrey's errors on Cygwin where the same, I think it's all that's missing there as well. I'll clean up my patches this week-end or on Monday and will ask you to give them a try. I'll merge them into 2.0 to make it easier for you to test, and will backport them to 1.9 once you confirm the issue is gone for you as well. I suspect Solaris versions older than 10 will need the same workaround as well, but it will only be a matter of adding a build option, which will be easy. I can't test there, my old Ultra5 is really sick... So stay tuned! Willy
Upcoming haproxy build fixes for Cygwin & AIX
Hi, I finally could figure how to work around the issues with very old linkers. I could work on this using a very old AIX machine we have here running AIX 5.1, so now that my test code works on it, I'm fairly confident more recent versions will as well, and given that Jeffrey's errors on Cygwin where the same, I think it's all that's missing there as well. I'll clean up my patches this week-end or on Monday and will ask you to give them a try. I'll merge them into 2.0 to make it easier for you to test, and will backport them to 1.9 once you confirm the issue is gone for you as well. I suspect Solaris versions older than 10 will need the same workaround as well, but it will only be a matter of adding a build option, which will be easy. I can't test there, my old Ultra5 is really sick... So stay tuned! Willy
Re: [ANNOUNCE] haproxy-1.9.6
Am 29.03.2019 um 14:25 schrieb Willy Tarreau: > Hi Aleks, > > On Fri, Mar 29, 2019 at 02:09:28PM +0100, Aleksandar Lazic wrote: >> With openssl are 2 tests failed but I'm not sure because of the setup or a >> bug. >> https://gitlab.com/aleks001/haproxy19-centos/-/jobs/186769272 > > Thank you for the quick feedback. I remember about the first one being > caused by a mismatch in the exact computed response size due to headers > encoding causing some very faint variations, though I have no idea why > I don't see it here, since I should as well, I'll have to check my regtest > script. For the second one, it looks related to the reactivation of the > HEAD method in this test which was broken in previous vtest. But I'm > seeing in your trace that you're taking it from the git repo so that > can't be that. I need to dig as well. > >> With boringssl are 3 tests failed but I'm not sure because of the setup or a >> bug. >> https://gitlab.com/aleks001/haproxy-19-boringssl/-/jobs/186780822 > > For this one I don't know, curl reports some unexpected EOFs. I don't > see why it would fail only with boringssl. Did it use to work in the > past ? No. The tests with Boringssl always failed in one or another way. https://gitlab.com/aleks001/haproxy-19-boringssl/-/jobs/157743825 https://gitlab.com/aleks001/haproxy-19-boringssl/-/jobs/157730793 I'm not sure if the docker setup on gitlab is the limitation or just a bug. Sorry to be so unspecific. > Thanks, > Willy Regards Aleks
Re: [ANNOUNCE] haproxy-1.9.6
Hi Aleks, On Fri, Mar 29, 2019 at 02:09:28PM +0100, Aleksandar Lazic wrote: > With openssl are 2 tests failed but I'm not sure because of the setup or a > bug. > https://gitlab.com/aleks001/haproxy19-centos/-/jobs/186769272 Thank you for the quick feedback. I remember about the first one being caused by a mismatch in the exact computed response size due to headers encoding causing some very faint variations, though I have no idea why I don't see it here, since I should as well, I'll have to check my regtest script. For the second one, it looks related to the reactivation of the HEAD method in this test which was broken in previous vtest. But I'm seeing in your trace that you're taking it from the git repo so that can't be that. I need to dig as well. > With boringssl are 3 tests failed but I'm not sure because of the setup or a > bug. > https://gitlab.com/aleks001/haproxy-19-boringssl/-/jobs/186780822 For this one I don't know, curl reports some unexpected EOFs. I don't see why it would fail only with boringssl. Did it use to work in the past ? Thanks, Willy
Re: [ANNOUNCE] haproxy-1.9.6
Am 29.03.2019 um 11:50 schrieb Willy Tarreau:
> Hi,
>
> HAProxy 1.9.6 was released on 2019/03/29. It added 34 new commits
> after version 1.9.5.
>
> As mentioned in the 2.0-dev2 release, we've addressed quite a number
> of issues recently and these fixes have now been backported into this
> release.
>
> Two issues affect checks and may occasionally cause crashes, one fixed
> by Olivier and the latest one by Ricardo Nabinger Sanchez. Christopher
> fixed two long standing problems, one affecting the way POST requests
> are processed by applets, which can sometimes leave data pending there
> unread forever, and another one related to the confusion created in
> 1.8's early H2 between an end of message and end of stream resulting
> in spurious aborts when option abortonclose is set. Olivier addressed
> a number of H2 stability issues, some related to connection error
> handling, other ones related to a lack of fairness between streams
> caused by the different stream processing flow in 1.9 vs 1.8 which can
> result in some streams facing a huge latency. Pierre Cheynier fixed
> the TLS 1.3 cipher suites, and William fixed a risk of crash in the
> master-worker code in the unlikely case where one of the embedded
> libraries would perform a fork() causing a waitpid() to succeed with
> an unregistered process. Radek Zajic fixed the IPv6 address hex format
> used in logs which seems to have been broken for a very long time, and
> Fred re-enabled the reg test we regularly disable when vtest breaks :-)
>
> And this is one of the first release in which I did almost nothing,
> which is awesome (it proves I'm no longer the bottleneck blocking the
> project's ability to scale), so keep up the good work guys!
>
> Please find the usual URLs below :
>Site index : http://www.haproxy.org/
>Discourse: http://discourse.haproxy.org/
>Slack channel: https://slack.haproxy.org/
>Issue tracker: https://github.com/haproxy/haproxy/issues
>Sources : http://www.haproxy.org/download/1.9/src/
>Git repository : http://git.haproxy.org/git/haproxy-1.9.git/
>Git Web browsing : http://git.haproxy.org/?p=haproxy-1.9.git
>Changelog: http://www.haproxy.org/download/1.9/src/CHANGELOG
>Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/
Container with openssl 1.1.1b and boringssl.
https://hub.docker.com/r/me2digital/haproxy19
With openssl are 2 tests failed but I'm not sure because of the setup or a bug.
https://gitlab.com/aleks001/haproxy19-centos/-/jobs/186769272
With boringssl are 3 tests failed but I'm not sure because of the setup or a
bug.
https://gitlab.com/aleks001/haproxy-19-boringssl/-/jobs/186780822
### openssl
HA-Proxy version 1.9.6 2019/03/29 - https://haproxy.org/
Build options :
TARGET = linux2628
CPU = generic
CC = gcc
CFLAGS = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv
-Wno-unused-label -Wno-sign-compare -Wno-unused-parameter
-Wno-old-style-declaration -Wno-ignored-qualifiers -Wno-clobbered
-Wno-missing-field-initializers -Wtype-limits
OPTIONS = USE_LINUX_SPLICE=1 USE_GETADDRINFO=1 USE_ZLIB=1 USE_REGPARM=1
USE_THREAD=1 USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1 USE_PCRE_JIT=1 USE_TFO=1
Default settings :
maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
Built with OpenSSL version : OpenSSL 1.1.1b 26 Feb 2019
Running on OpenSSL version : OpenSSL 1.1.1b 26 Feb 2019
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
Built with Lua version : Lua 5.3.5
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
IP_FREEBIND
Built with zlib version : 1.2.7
Running on zlib version : 1.2.7
Compression algorithms supported : identity("identity"), deflate("deflate"),
raw-deflate("deflate"), gzip("gzip")
Built with PCRE version : 8.32 2012-11-30
Running on PCRE version : 8.32 2012-11-30
PCRE library supports JIT : yes
Encrypted password support via crypt(3): yes
Built with multi-threading support.
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.
Available multiplexer protocols :
(protocols marked as cannot be specified using 'proto' keyword)
h2 : mode=HTXside=FE|BE
h2 : mode=HTTP side=FE
: mode=HTXside=FE|BE
: mode=TCP|HTTP side=FE|BE
Available filters :
[SPOE] spoe
[COMP] compression
[CACHE] cache
[TRACE] trace
###
Boringssl
###
HA-Proxy version 1.9.6 2019/03/29 - https://haproxy.org/
Build options :
TARGET = linux2628
CPU = generic
CC = gcc
CFLAGS = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv
-Wno-unused-label -Wno-sign-compare -Wno-unused-parameter
-Wno-old-style-declaration -Wno-ignored-qualifiers
[ANNOUNCE] haproxy-1.9.6
Hi, HAProxy 1.9.6 was released on 2019/03/29. It added 34 new commits after version 1.9.5. As mentioned in the 2.0-dev2 release, we've addressed quite a number of issues recently and these fixes have now been backported into this release. Two issues affect checks and may occasionally cause crashes, one fixed by Olivier and the latest one by Ricardo Nabinger Sanchez. Christopher fixed two long standing problems, one affecting the way POST requests are processed by applets, which can sometimes leave data pending there unread forever, and another one related to the confusion created in 1.8's early H2 between an end of message and end of stream resulting in spurious aborts when option abortonclose is set. Olivier addressed a number of H2 stability issues, some related to connection error handling, other ones related to a lack of fairness between streams caused by the different stream processing flow in 1.9 vs 1.8 which can result in some streams facing a huge latency. Pierre Cheynier fixed the TLS 1.3 cipher suites, and William fixed a risk of crash in the master-worker code in the unlikely case where one of the embedded libraries would perform a fork() causing a waitpid() to succeed with an unregistered process. Radek Zajic fixed the IPv6 address hex format used in logs which seems to have been broken for a very long time, and Fred re-enabled the reg test we regularly disable when vtest breaks :-) And this is one of the first release in which I did almost nothing, which is awesome (it proves I'm no longer the bottleneck blocking the project's ability to scale), so keep up the good work guys! Please find the usual URLs below : Site index : http://www.haproxy.org/ Discourse: http://discourse.haproxy.org/ Slack channel: https://slack.haproxy.org/ Issue tracker: https://github.com/haproxy/haproxy/issues Sources : http://www.haproxy.org/download/1.9/src/ Git repository : http://git.haproxy.org/git/haproxy-1.9.git/ Git Web browsing : http://git.haproxy.org/?p=haproxy-1.9.git Changelog: http://www.haproxy.org/download/1.9/src/CHANGELOG Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/ Willy --- Complete changelog : Christopher Faulet (12): BUG/MINOR: cache: Fully consume large requests in the cache applet BUG/MINOR: stats: Fully consume large requests in the stats applet BUG/MEDIUM: lua: Fully consume large requests when an HTTP applet ends BUG/MINOR: proto-http: Don't forward request body anymore on error MINOR: mux-h2: Remove useless test on ES flag in h2_frt_transfer_data() MINOR: connection: and new flag to mark end of input (EOI) MINOR: channel: Report EOI on the input channel if it was reached in the mux MEDIUM: mux-h2: Don't mix the end of the message with the end of stream MINOR: mux-h1: Set CS_FL_EOI the end of the message is reached BUG/MEDIUM: http/htx: Fix handling of the option abortonclose CLEANUP: muxes/stream-int: Remove flags CS_FL_READ_NULL and SI_FL_READ_NULL BUG/MINOR: mux-h1: Only skip invalid C-L headers on output Freddy Spierenburg (1): DOC: The option httplog is no longer valid in a backend. Frédéric Lécaille (1): REGTEST: Enable again reg tests with HEAD HTTP method usage. Olivier Houchard (10): BUG/MEDIUM: mux-h2: Make sure we destroyed the h2s once shutr/shutw is done. BUG/MEDIUM: mux-h2: Don't bother keeping the h2s if detaching and nothing to send. BUG/MEDIUM: mux-h2: Use the right list in h2_stop_senders(). BUG/MINOR: doc: Be accurate on the behavior on pool-purge-delay. BUG/MEDIUM: h2: Try to be fair when sending data. BUG/MEDIUM: h2: only destroy the h2s if h2s->cs is NULL. BUG/MEDIUM: h2: Use the new sending_list in h2s_notify_send(). BUG/MEDIUM: h2: Follow the same logic in h2_deferred_shut than in h2_snd_buf. BUG/MEDIUM: h2: Remove the tasklet from the task list if unsubscribing. BUG/MEDIUM: checks: Don't bother subscribing if we have a connection error. Pierre Cheynier (1): BUG/MEDIUM: ssl: ability to set TLS 1.3 ciphers using ssl-default-server-ciphersuites Radek Zajic (1): BUG/MINOR: log: properly format IPv6 address when LOG_OPT_HEXA modifier is used. Ricardo Nabinger Sanchez (1): BUG/MAJOR: checks: segfault during tcpcheck_main William Lallemand (1): BUG/MEDIUM: mworker: don't free the wrong child when not found Willy Tarreau (6): MINOR: mux-h2: copy small data blocks more often and reduce the number of pauses MINOR: lists: add a LIST_DEL_INIT() macro CONTRIB: debug: report the CS and CF's EOI flags BUG/MEDIUM: mux-h2: make sure to always notify streams of EOS condition BUG/MEDIUM: task/h2: add an idempotent task removal fucntion REGTEST: remove unexpected "nbthread" statement from Lua test cases ---
AW: 400 SC on h2 xhr post
N¬Æ§Kó0K"wë,j»÷Pý:]xÐAãPÓNûm¸ S¡h¥$Ú®·»
pµë
©®r~æ[±¢¸!jèÇ'è®h¥»++ç-n4Ñ ¨ ±ºh²ÐÚµákoLj½´×ÝtãÝ·ûM4Ð*'µéí-©à¹¨ uàÄ
íz{SÊ{¦V¢ÈZ®Ç
Re: [PATCH] BUG/MAJOR: segfault during tcpcheck_main
Hi Ricardo, On Thu, Mar 28, 2019 at 10:15:41PM -0300, Ricardo Nabinger Sanchez wrote: > Hello, > > We have been chasing a segfault for a few weeks and today we were able > to track it down. There is a null-pointer dereferencing when using > tcp-check connect; although we don't know yet as to why the protocol > family might be unknown during tcpcheck_main(). Many thanks for this fix! I think I'm seeing how this can happen, it's probably since the introduction of the DNS to set addresses on servers. In the past a server always had an address, but now a server may also not have an address at all. It's unclear to me exactly how a check could be scheduled on an addressless server but I think it could happen if the check is already scheduled and the server loses its address just before the check actually runs. I'm taking it just before issuing 1.9.6, thanks! Willy
Re: FEATURE: Add range iterator item variable for server-template and zero-padding converter
Hi. Am 29.03.2019 um 09:34 schrieb Matous Jan Fialka: > Hello, > > please consider adding range iterator item variable (say `rng.iteritem`) for > the `server-template` directive so that it can be expanded in the > `:` > part of the statement or anywhere else where applicable (see in the example > snippet > below). > > Also to have general zero-padding converter (say `zeropad()`) to pad > values > with zeroes would be splendid for use with `server-template` or elsewhere > (therefor > I aggregated both things into single feature request). Please can you open a issue for that Feature Request, thanks. https://github.com/haproxy/haproxy/issues Regards Aleks > -snip- > > zeropad() > Performs a zero-padding of preceding expression to the given . > > Example: > server-template s 3 "svc-%[rng.iteritem,zeropad(3)].domain.tld:80" > check > > # would be equivalent to: > server s1 svc-001.domain.tld:80 check > server s2 svc-002.domain.tld:80 check > server s3 svc-003.domain.tld:80 check > > -snip- > > I am not sure how hard it would be to implemented it but it could be very > helpful > in case you use many backend servers with consistent sequential naming as > shown in > the example snippet. > > Many thanks for providing us wich such an excellent piece of software which > *HAProxy* > truly is! > > Sincerely, >
FEATURE: Add range iterator item variable for server-template and zero-padding converter
Hello, please consider adding range iterator item variable (say `rng.iteritem`) for the `server-template` directive so that it can be expanded in the `:` part of the statement or anywhere else where applicable (see in the example snippet below). Also to have general zero-padding converter (say `zeropad()`) to pad values with zeroes would be splendid for use with `server-template` or elsewhere (therefor I aggregated both things into single feature request). -snip- zeropad() Performs a zero-padding of preceding expression to the given . Example: server-template s 3 "svc-%[rng.iteritem,zeropad(3)].domain.tld:80" check # would be equivalent to: server s1 svc-001.domain.tld:80 check server s2 svc-002.domain.tld:80 check server s3 svc-003.domain.tld:80 check -snip- I am not sure how hard it would be to implemented it but it could be very helpful in case you use many backend servers with consistent sequential naming as shown in the example snippet. Many thanks for providing us wich such an excellent piece of software which *HAProxy* truly is! Sincerely, -- mjf
