Re: corruption of data with compression in 1.9-dev10
On 12/12/18 2:08 AM, PiBa-NL wrote:
Hi List,
Didn't have time yet to bisect when it went wrong. But attached testfile
produces the following output after 3 curl requests at different speeds,
this seems to trigger a problem as the hash of the downloaded content is
nolonger the same as it should be, (in my actual environment its a 2MB
javascript file that comes from a iis server behind haproxy.). Took
already a few hours more than desired to come up with a seemingly
reliable reproduction.
1.9-dev10 is the first one i put on my production environment as i think
release is imminent so it 'should' be pretty stable ;), (yes i know..i
shouldn't assume..) before it was using 1.8.14.. So was quick to revert
to that 1.8 again :).
Hello Pieter,
I think your scripts would deserve to be used in haproxy sources as reg
tests.
Why not sending them to the ML?
Find attached to this mail a patch to make it work both on Linux and
Freebsd systems.
If you decide to send us, you would have to modify the LUA code so that
the HTTP service would not produce pseudo-random HTTP contents (bote
that I had to modify the MD5 checksum to make it work on Linux).
Regards,
Fred.
diff --git a/reg-tests/filters/b5.vtc b/reg-tests/filters/b5.vtc
index 0cb62633..81567210 100644
--- a/reg-tests/filters/b5.vtc
+++ b/reg-tests/filters/b5.vtc
@@ -34,40 +34,16 @@ shell {
if [ "${h1_fe1_addr}" = "::1" ] ; then
HOST="\[::1\]"
fi
-curl --compressed -k "https://$HOST:${h1_fe1_port}"; -o
${tmpdir}/outputfile1.bin
-curl --compressed -k "https://$HOST:${h1_fe1_port}"; -o
${tmpdir}/outputfile3.bin --limit-rate 300K
-curl --compressed -k "https://$HOST:${h1_fe1_port}"; -o
${tmpdir}/outputfile2.bin --limit-rate 500K
-} -run
-shell {
-md5sum=$(md5 -q ${tmpdir}/outputfile1.bin)
-if [ "$md5sum" = "f0d51d274ebc7696237efec272a38c41" ]
-then
- echo "File1 all OK"
-else
- echo "File1 not OK $md5sum "
- testfailed=1
-fi
+md5=$(which md5 || which md5sum)
-md5sum=$(md5 -q ${tmpdir}/outputfile2.bin)
-if [ "$md5sum" = "f0d51d274ebc7696237efec272a38c41" ]
-then
- echo "File2 all OK"
-else
- echo "File2 not OK $md5sum "
- testfailed=1
+if [ -z $md5 ] ; then
+echo "MD5 checksum utility not found"
+exit 1
fi
-md5sum=$(md5 -q ${tmpdir}/outputfile3.bin)
-if [ "$md5sum" = "f0d51d274ebc7696237efec272a38c41" ]
-then
- echo "File3 all OK"
-else
- echo "File3 not OK $md5sum "
- testfailed=1
-fi
-
-if [ -n "$testfailed" ]; then
- exit 1
-fi
-} -run
\ No newline at end of file
+for opt in "" "--limit-rate 300K" "--limit-rate 500K" ; do
+checksum=$(curl --compressed -k "https://$HOST:${h1_fe1_port}"; $opt |
$md5 | cut -d ' ' -f1)
+if [ "$checksum" != "0a55287fd57c5e4d19f48a9e33e53b05" ] ; then exit
1; fi
+done
+} -run
Re: Http HealthCheck Issue
Hi, On Tue, Dec 18, UPPALAPATI, PRAVEEN wrote: > My backend config is: > > backend bk_8093_read > balancesource > http-response set-header X-Server %s > option log-health-checks > option httpchk get > /nexus/v1/repository/rawcentral/com.att.swm.attpublic/healthcheck.txt > HTTP/1.1\r\nAuthorization:\ Basic\ Change get to GET, at least apache, ngingx and tomcat expect GET not get. Or test with for example netcat that your server1 accepts get. Something like: nc server1.add.re.ss 8093 get /nexus/v1/repository/rawcentral/com.att.swm.attpublic/healthcheck.txt HTTP/1.1 Host: ... Authorization: Basic ... > server primary8093r :8093 check verify none > server backUp08093r ::8093 check backup verify none > server backUp18093r ::8093 check backup verify none > > Output of log: > > [Dec 18 05:22:51] Health check for server bk_8093_read/primary8093r failed, > reason: Layer7 wrong status, code: 400, info: "No Host", check duration: > 543ms, status: 0/2 DOWN. Like Jonathan said "No Host" is telling you what's wrong. (HTTP/1.1 requests expect Host: header). -Jarno -- Jarno Huuskonen
Re: [ANNOUNCE] haproxy-1.9-dev11
Hello, Le 17/12/2018 à 20:16, Willy Tarreau a écrit : Hi Arnall, On Mon, Dec 17, 2018 at 02:13:31PM +0100, Arnall wrote: don't know if it's related but haproxy.org answers with 400 status right now ! (Windows 10 Chrome/Firefox) Might be, though I can't reproduce it. I've found a capture of an attack however, with shell code in the user-agent, and which definitely deserves a 400 :-) Do you still observe it ? Thanks, Willy Everything's OK now ! Thanks.
Re: d94f877 causes timeout in a basic connection test 1.9-dev11_d94f877
On Tue, Dec 18, 2018 at 11:43:44AM +0100, Christopher Faulet wrote:
> Le 18/12/2018 à 00:32, PiBa-NL a écrit :
> > Hi List, Christopher,
> >
> > Seems like d94f877 causes timeout in a pretty 'basic' connection test
> > that transfers a little bit of data .?
> > Or at least attached test fails to complete for me..
> >
> > # top TEST ./PB-TEST/basic_connection.vtc TIMED OUT (kill -9)
> > # top TEST ./PB-TEST/basic_connection.vtc FAILED (120.236) signal=9
> >
> > Please can you take a look :) Thanks in advance.
> >
>
> Hi Pieter,
>
> I've run your reg-test and everything works find for me. But I'll try to do
> more test to reproduce your problem.
Sorry guys, we found it last evening with Olivier and I fixed it this
morning, but I forgot to mention it, it's normally fixed with this one :
commit 7ab99a302d37d3d39ee6c8094e3a0c154ce5896b
Author: Willy Tarreau
Date: Tue Dec 18 09:15:43 2018 +0100
BUG/MEDIUM: stream-int: always clear CS_FL_WANT_ROOM before receiving
Commit d94f877cd ("BUG/MINOR: mux_pt: Set CS_FL_WANT_ROOM when count is
zero in rcv_buf() callback") triggered a pending issue with this flag,
which is that it's cleared too late and sometimes causes some Rx
transfers to stall. We need to clear it before attempting to receive
otherwise we may risk to see an earlier copy of the flag.
Note that it should probably be defined that this flag could be purged
on each invocation of mux->rcv_buf(), which would make sense.
No backport is needed.
Please note that a few other issues affecting the H2 mux have been fixed
recently so it makes sense to rebase on the latest master right now.
On another note, aside the occasional HTTP 400 that were reported on
haproxy.org, we've had no single crash nor memory leak since saturday.
I've updated to dev11 this morning after 2 full more days, so I'm much
more confident in what we have right now and I'm planning on releasing
tomorrow after the last polishing (and my last minute bugs of course).
Cheers,
Willy
Re: Http HealthCheck Issue
On Tue, 18 Dec 2018 at 14:56, UPPALAPATI, PRAVEEN wrote: > > wcentral/com.att.swm.attpublic/healthcheck.txt HTTP/1.1\r\nAuthorization:\ > Basic\ > > [Dec 18 05:22:51] Health check for server bk_8093_read/primary8093r > failed, reason: Layer7 wrong status, code: 400, info: "No Host", check > duration: 543ms, status: 0/2 DOWN Hey there, Praveen. This log line is literally telling you what your problem is! I know different folks like the satisfaction of discovering their own solutions, so I'll ask before simply telling you the solution: do you need help in finding the error hidden in that log line, or can you manage to fix it? All the best, Jon -- Jonathan Matthews London, UK http://www.jpluscplusm.com/contact.html
RE: Http HealthCheck Issue
Hi Jarno, My backend config is: backend bk_8093_read balancesource http-response set-header X-Server %s option log-health-checks option httpchk get /nexus/v1/repository/rawcentral/com.att.swm.attpublic/healthcheck.txt HTTP/1.1\r\nAuthorization:\ Basic\ server primary8093r :8093 check verify none server backUp08093r ::8093 check backup verify none server backUp18093r ::8093 check backup verify none Output of log: [Dec 18 05:22:51] Health check for server bk_8093_read/primary8093r failed, reason: Layer7 wrong status, code: 400, info: "No Host", check duration: 543ms, status: 0/2 DOWN. [Dec 18 05:27:36] Health check for server bk_8093_read/primary8093r failed, reason: Layer7 timeout, check duration: 2001ms, status: 0/2 DOWN. [Dec 18 05:27:40] Health check for server bk_8093_read/primary8093r failed, reason: Layer7 wrong status, code: 400, info: "No Host", check duration: 1829ms, status: 0/2 DOWN. [Dec 18 05:30:14] Health check for server bk_8093_read/primary8093r failed, reason: Layer7 timeout, check duration: 2001ms, status: 0/2 DOWN. [Dec 18 05:30:22] Health check for server bk_8093_read/primary8093r failed, reason: Layer7 wrong status, code: 400, info: "No Host", check duration: 1903ms, status: 0/2 DOWN. [Dec 18 05:32:34] Health check for server bk_8093_read/primary8093r failed, reason: Layer7 timeout, check duration: 2001ms, status: 0/2 DOWN. [Dec 18 05:32:36] Health check for server bk_8093_read/primary8093r failed, reason: Layer7 wrong status, code: 400, info: "No Host", check duration: 126ms, status: 0/2 DOWN. [Dec 18 05:36:28] Health check for backup server bk_8093_read/backUp18093r failed, reason: Socket error, info: "Connection reset by peer", check duration: 117ms, status: 0/2 DOWN. [Dec 18 05:36:30] Health check for backup server bk_8093_read/backUp18093r failed, reason: Layer4 connection problem, info: "Connection refused", check duration: 58ms, status: 0/2 DOWN. [Dec 18 06:01:44] Health check for server bk_8093_read/primary8093r failed, reason: Layer7 timeout, check duration: 2001ms, status: 0/2 DOWN. [Dec 18 06:01:50] Health check for server bk_8093_read/primary8093r failed, reason: Layer7 wrong status, code: 400, info: "No Host", check duration: 235ms, status: 0/2 DOWN. [Dec 18 06:02:13] Health check for server bk_8093_read/primary8093r failed, reason: Layer7 timeout, check duration: 2001ms, status: 0/2 DOWN. [Dec 18 06:02:19] Health check for server bk_8093_read/primary8093r failed, reason: Layer7 wrong status, code: 400, info: "No Host", check duration: 125ms, status: 0/2 DOWN. [Dec 18 06:02:26] Health check for server bk_8093_read/primary8093r failed, reason: Layer7 timeout, check duration: 2000ms, status: 0/2 DOWN. [Dec 18 06:02:28] Health check for server bk_8093_read/primary8093r failed, reason: Layer7 wrong status, code: 400, info: "No Host", check duration: 115ms, status: 0/2 DOWN. [Dec 18 06:09:31] Health check for server bk_8093_read/primary8093r failed, reason: Layer7 timeout, check duration: 2001ms, status: 0/2 DOWN. [Dec 18 06:09:42] Health check for server bk_8093_read/primary8093r failed, reason: Layer7 wrong status, code: 400, info: "No Host", check duration: 1027ms, status: 0/2 DOWN. [Dec 18 06:12:12] Health check for server bk_8093_read/primary8093r failed, reason: Layer7 timeout, check duration: 2000ms, status: 0/2 DOWN. [Dec 18 06:12:22] Health check for server bk_8093_read/primary8093r failed, reason: Layer7 wrong status, code: 400, info: "No Host", check duration: 119ms, status: 0/2 DOWN. [Dec 18 06:12:34] Health check for server bk_8093_read/primary8093r failed, reason: Layer7 timeout, check duration: 2001ms, status: 0/2 DOWN. [Dec 18 06:12:36] Health check for server bk_8093_read/primary8093r failed, reason: Layer7 wrong status, code: 400, info: "No Host", check duration: 116ms, status: 0/2 DOWN. [Dec 18 06:17:35] Health check for server bk_8093_read/primary8093r failed, reason: Layer7 timeout, check duration: 2001ms, status: 0/2 DOWN. [Dec 18 06:17:42] Health check for server bk_8093_read/primary8093r failed, reason: Layer7 wrong status, code: 400, info: "No Host", check duration: 1210ms, status: 0/2 DOWN. [haproxy@zld05596 ~]$ Before we used to rely on TCP health check but that is not working when server is in hung state, so wanted to switch to http log where we check if the server is responding and have no luck in getting that working. Any help will be highly apprecuiated. Thanks, Praveen. -Original Message- From: Jarno Huuskonen [mailto:jarno.huusko...@uef.fi] Sent: Tuesday, December 18, 2018 1:11 AM To: UPPALAPATI, PRAVEEN Cc: haproxy@formilux.org Subject: Re: Http HealthCheck Issue Hi, On Mon, Dec 17, UPPALAPATI, PRAVEEN wrote: > I am trying to use Option httpHealth Check is not working and is marking all > servers as down: > > > [haproxy@zld05596 ~]$ cat //opt/app/haproxy/etc/haproxy.cfg | grep /nexus/v1 > option httpchk get > /nexus/
Re: Setting a unique header per server in a backend
Thankyou Willy. http-send-name-header works for my use case. @Norman - Yes, we are looking at replacing the usage of X- headers. Thanks Sachin On Mon, Dec 17, 2018 at 2:18 AM Norman Branitsky < norman.branit...@micropact.com> wrote: > Don't forget the "X-" header prefix is deprecated: > https://tools.ietf.org/html/rfc6648 > > Norman Branitsky > > On Dec 16, 2018, at 03:50, Willy Tarreau wrote: > > Hi Sachin, > > On Sat, Dec 15, 2018 at 10:32:21PM +0530, Sachin Shetty wrote: > > Hi, > > > We have a tricky requirement to set a different header value in the request > > based on which server in a backend is picked. > > > backend pod0 > >... > >server server1 server1:6180 check > >server server2 server2:6180 check > >server server3 server3:6180 check > > > so when request is forwarded to server1 - I want to inject an header > > "X-Some-Header: Server1", "X-Some-Header: Server2" for server 2 and so > > on. > > > You have this with "http-send-name-header", you need to pass it the > header field name and it will fill the value with the server's name. > It will even support redispatch by rewinding the stream and rewriting > the value (which made it very tricky and infamous for quite some time). > > If it possible to register some lua action that would inject the header > > based on the server selected before the request is forwarded to the > server. > > > In fact except for the directive above it's not possible to perform > changes after the server has been selected, because the server is > selected when trying to connect, which happens after the contents are > being forwarded, thus you can't perform any processing anymore. There > is quite some ugly code to support http-send-name-header and it cannot > be generalized at all. Just to give you an idea, think that a hash-based > LB algo (balance uri, balance hdr) could decide to use some contents > you're about to modify... So the contents have to be fixed before the > server is chosen. > > Cheers, > Willy > >
Re: d94f877 causes timeout in a basic connection test 1.9-dev11_d94f877
Le 18/12/2018 à 00:32, PiBa-NL a écrit : Hi List, Christopher, Seems like d94f877 causes timeout in a pretty 'basic' connection test that transfers a little bit of data .? Or at least attached test fails to complete for me.. # top TEST ./PB-TEST/basic_connection.vtc TIMED OUT (kill -9) # top TEST ./PB-TEST/basic_connection.vtc FAILED (120.236) signal=9 Please can you take a look :) Thanks in advance. Hi Pieter, I've run your reg-test and everything works find for me. But I'll try to do more test to reproduce your problem. Thanks, -- Christopher Faulet
Re: [ANNOUNCE] haproxy-1.9-dev11
Hi Cyril,
On Tue, Dec 18, 2018 at 09:11:26AM +0100, Cyril Bonté wrote:
> There's a bug with cookies and HTX.
> When haproxy sends the headers to the backend server, it leaks 6 more bytes
> at the end of the cookie value, which is the length of the name "cookie".
>
> This is due to this part of code :
> http://git.haproxy.org/?p=haproxy.git;a=blob;f=src/h2.c;h=1b784fd4aba2dbad91db156612243e93aa34e5f3;hb=HEAD#l533
>
> http://git.haproxy.org/?p=haproxy.git;a=blob;f=src/h2.c;h=1b784fd4aba2dbad91db156612243e93aa34e5f3;hb=HEAD#l557
> htx_set_blk_value_len(blk, bs + 2 + vl);
>
> Here, we set the new block value length, but bs is not the value length, it
> the whole block size :
> http://git.haproxy.org/?p=haproxy.git;a=blob;f=src/h2.c;h=1b784fd4aba2dbad91db156612243e93aa34e5f3;hb=HEAD#l542
> 542blk = htx_add_header(htx, ist("cookie"), list[ck].v);
> 543if (!blk)
> 544 goto fail;
> 545
> 546fs = htx_free_data_space(htx);
> 547bs = htx_get_blksz(blk);
>
> I'm not sure how to fix this properly. I'd say we can store list[ck].v in a
> "bvl" variable, update this variable while looping on the cookie values,
> then set the new block value length according to this result.
Ah you're totally right, good catch!
> Or is there a function to explicitely update the block size (kind of
> htx_set_blksz) ?
I don't know :-) But I find it safer to only adjust the value's length
anyway. I agree with your suggestion to keep the total value length, I'll
do this.
> I prefer to report the bug quickly so you can fix it today. Or I can work on
> a patch, but this will not be before the end of the day ;-)
No that's perfect, I'll do it right now. Thank you!
Willy
[PATCH 1/1] REGTEST: Add a reg test for health-checks over SSL/TLS.
From: Frédéric Lécaille
This script runs two tests. One with "httpchk" over SSL/TLS and another
one with "check-ssl" option. As varnishtest does not support SSL/TLS
we use two haproxy processes to run these tests. h2 haproxy process
be2 and be4 backends declare one server each wich are the frontend
of h1 haproxy process. We check the layer6/7 checks thanks to syslog
messages.
Signed-off-by: Frédéric Lécaille
---
reg-tests/checks/common.pem | 1 +
reg-tests/checks/s4.vtc | 99 +
2 files changed, 100 insertions(+)
create mode 12 reg-tests/checks/common.pem
create mode 100644 reg-tests/checks/s4.vtc
diff --git a/reg-tests/checks/common.pem b/reg-tests/checks/common.pem
new file mode 12
index ..a4433d56
--- /dev/null
+++ b/reg-tests/checks/common.pem
@@ -0,0 +1 @@
+../ssl/common.pem
\ No newline at end of file
diff --git a/reg-tests/checks/s4.vtc b/reg-tests/checks/s4.vtc
new file mode 100644
index ..1caeea1b
--- /dev/null
+++ b/reg-tests/checks/s4.vtc
@@ -0,0 +1,99 @@
+varnishtest "Health-check test over TLS/SSL"
+feature ignore_unknown_macro
+
+
+# This script tests health-checks for a TLS/SSL backend with "option httpchk"
+# and "check-ssl" option enabled attached to h2 haproxy process. This haproxy
+# h2 process is chained to h1 other one.
+#
+server s1 {
+rxreq
+expect req.method == OPTIONS
+expect req.url == *
+expect req.proto == HTTP/1.1
+txresp
+} -start
+
+server s2 {
+} -start
+
+syslog S1 -level notice {
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe1 started."
+recv info
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: .* fe1~ be1/srv1 .* 200 [[:digit:]]+ -
- .* \"OPTIONS \\* HTTP/1.1\""
+recv info
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: .* fe1~ be1/srv1 .* 504 [[:digit:]]+ -
- sH-- .* \"OPTIONS \\* HTTP/1.1\""
+} -start
+
+haproxy h1 -conf {
+global
+tune.ssl.default-dh-param 2048
+
+defaults
+mode http
+timeout client 1s
+timeout server 1s
+timeout connect 1s
+
+backend be1
+server srv1 ${s1_addr}:${s1_port}
+
+backend be2
+server srv2 ${s2_addr}:${s2_port}
+
+frontend fe1
+option httplog
+log ${S1_addr}:${S1_port} len 2048 local0 debug err
+bind "fd@${fe1}" ssl crt ${testdir}/common.pem
+use_backend be1
+
+frontend fe2
+option tcplog
+bind "fd@${fe2}" ssl crt ${testdir}/common.pem
+use_backend be2
+} -start
+
+syslog S2 -level notice {
+recv
+expect ~ "[^:\\[ ]\\[${h2_pid}\\]: Proxy be2 started."
+recv
+expect ~ "[^:\\[ ]\\[${h2_pid}\\]: Health check for server be2/srv1
succeeded, reason: Layer7 check passed, code: 200, info: \"OK\", check
duration: [[:digit:]]+ms, status: 1/1 UP."
+recv
+expect ~ "[^:\\[ ]\\[${h2_pid}\\]: Health check for server be2/srv1
failed, reason: Layer7 wrong status, code: 504, info: \"Gateway Time-out\",
check duration: [[:digit:]]+ms, status: 0/1 DOWN."
+} -start
+
+syslog S4 -level notice {
+recv
+expect ~ "[^:\\[ ]\\[${h2_pid}\\]: Proxy be4 started."
+recv
+expect ~ "[^:\\[ ]\\[${h2_pid}\\]: Health check for server be4/srv2
succeeded, reason: Layer6 check passed, check duration: [[:digit:]]+ms, status:
1/1 UP."
+} -start
+
+haproxy h2 -conf {
+global
+tune.ssl.default-dh-param 2048
+
+defaults
+timeout client 1s
+timeout server 1s
+timeout connect 1s
+default-server downinter 1s rise 1 fall 1
+
+backend be2
+option log-health-checks
+option httpchk OPTIONS * HTTP/1.1\r\nHost:\ www
+log ${S2_addr}:${S2_port} daemon
+server srv1 ${h1_fe1_addr}:${h1_fe1_port} ssl crt
${testdir}/common.pem verify none check
+
+backend be4
+option log-health-checks
+log ${S4_addr}:${S4_port} daemon
+server srv2 ${h1_fe2_addr}:${h1_fe2_port} ssl crt
${testdir}/common.pem verify none check-ssl check
+} -start
+
+syslog S1 -wait
+
+syslog S2 -wait
+syslog S4 -wait
+
--
2.11.0
Re: haproxy.org, Suggestions to increase your business
Hi haproxy.org, Hope you are doing fantastic. I am Alex Sr. Web Analyzer having 9+ years of experience in Search Engine Marketing, Social media Marketing, Content Marketing, Pay-per-click, Video Marketing etc. While analyzing your website, we tracked some pitfalls for which your website doesn’t show up within top search results on search engines including Google. In addition to the same, we found that haproxy.org is not able to achieve appropriate traffic/visitors for a couple of months. I am quite impressed with your website - Business Concept, Content, Call-to-Actions and others. As a web analyzer, I can recommend few things to improve the website performance and I hope my suggestions will help business & your website. My suggestions: • Publish Relevant Content (Blogs, Micro blogs, Article, Business Bio and etc) • Update Your Content regularly for quick crawling • Go for variation keywords and website optimization • Update Best Title Metadata, Description Metadata, Keyword Metadata • Go for Social media marketing for more engagement and social media traffic • Work on Page Loading speed and fix it to load within seconds • Go for Content marketing and Video marketing • Implement Latest Industry Specific Schema so you stand out as compared to your competitors’ not sure, if you can understand all above technical terms or not. Not to be worried, I will help to make you understand about the above points with brief descriptions. If you have a technical team then I will wish you to go ahead and work on the above factors or if you prefer then I can help you to work on the above points. If you are comfortable to go for a online meeting then please let me know. If you need to know about the cost then please revert back to my email and I will be happy to send you the quote with brief recommendation. Thanks, I look forward to your reply. Regards, *Alex | Cretivedigitalagency* Web Analyzer [image: beacon]
Re: haproxy.com, Suggestions to increase your business
Hi haproxy.com, Hope you are doing fantastic. I am Alex Sr. Web Analyzer having 9+ years of experience in Search Engine Marketing, Social media Marketing, Content Marketing, Pay-per-click, Video Marketing etc. While analyzing your website, we tracked some pitfalls for which your website doesn’t show up within top search results on search engines including Google. In addition to the same, we found that haproxy.com is not able to achieve appropriate traffic/visitors for a couple of months. I am quite impressed with your website - Business Concept, Content, Call-to-Actions and others. As a web analyzer, I can recommend few things to improve the website performance and I hope my suggestions will help business & your website. My suggestions: • Publish Relevant Content (Blogs, Micro blogs, Article, Business Bio and etc) • Update Your Content regularly for quick crawling • Go for variation keywords and website optimization • Update Best Title Metadata, Description Metadata, Keyword Metadata • Go for Social media marketing for more engagement and social media traffic • Work on Page Loading speed and fix it to load within seconds • Go for Content marketing and Video marketing • Implement Latest Industry Specific Schema so you stand out as compared to your competitors’ not sure, if you can understand all above technical terms or not. Not to be worried, I will help to make you understand about the above points with brief descriptions. If you have a technical team then I will wish you to go ahead and work on the above factors or if you prefer then I can help you to work on the above points. If you are comfortable to go for a online meeting then please let me know. If you need to know about the cost then please revert back to my email and I will be happy to send you the quote with brief recommendation. Thanks, I look forward to your reply. Regards, *Alex | Cretivedigitalagency* Web Analyzer [image: beacon]
Re: [ANNOUNCE] haproxy-1.9-dev11
Hi Willy,
Le 17/12/2018 à 14:13, Arnall a écrit :
Le 16/12/2018 à 23:05, Willy Tarreau a écrit :
I expected to release this week-end after running it on the haproxy.org
servers, but some annoying issues faced in production took some time to
get fixed and delayed the release.
Things have been quiet now, with 18 hours running without a glitch in
legacy mode (without HTX) and now 13 hours an counting with HTX enabled,
so things are getting much better.
Hello Willy,
don't know if it's related but haproxy.org answers with 400 status right
now !
(Windows 10 Chrome/Firefox)
I think I have met the exact same issue when I enabled HTX on a small
test config.
There's a bug with cookies and HTX.
When haproxy sends the headers to the backend server, it leaks 6 more
bytes at the end of the cookie value, which is the length of the name
"cookie".
This is due to this part of code :
http://git.haproxy.org/?p=haproxy.git;a=blob;f=src/h2.c;h=1b784fd4aba2dbad91db156612243e93aa34e5f3;hb=HEAD#l533
http://git.haproxy.org/?p=haproxy.git;a=blob;f=src/h2.c;h=1b784fd4aba2dbad91db156612243e93aa34e5f3;hb=HEAD#l557
htx_set_blk_value_len(blk, bs + 2 + vl);
Here, we set the new block value length, but bs is not the value length,
it the whole block size :
http://git.haproxy.org/?p=haproxy.git;a=blob;f=src/h2.c;h=1b784fd4aba2dbad91db156612243e93aa34e5f3;hb=HEAD#l542
542blk = htx_add_header(htx, ist("cookie"), list[ck].v);
543if (!blk)
544 goto fail;
545
546fs = htx_free_data_space(htx);
547bs = htx_get_blksz(blk);
I'm not sure how to fix this properly. I'd say we can store list[ck].v
in a "bvl" variable, update this variable while looping on the cookie
values, then set the new block value length according to this result.
Or is there a function to explicitely update the block size (kind of
htx_set_blksz) ?
I prefer to report the bug quickly so you can fix it today. Or I can
work on a patch, but this will not be before the end of the day ;-)
--
Cyril Bonté
