Re: Building HAProxy 1.8 fails on Solaris
So...is there a way to adapt this patch so it won't cause random SSL errors and is suitable to apply to the trunk? We don't really want to run a customised build in production... On Wednesday, 18 July 2018, 10:45:38 pm AEST, Olivier Houchard wrote: Hi, On Wed, Jul 18, 2018 at 02:17:59AM +, Thrawn wrote: > Mea culpa, I applied the patch incorrectly. After fixing that, I can > successfully build with 'USE_THREAD=' but without 'USE_PTHREAD_PSHARED=yes' > (although from what Olivier said, I probably shouldn't do that). On > Wednesday, 18 July 2018, 12:10:57 pm AEST, Thrawn > wrote: Yeah the patch may get you to experience random errors if you share a SSL cache across multiple process, USE_PTHREAD_PSHARED=yes should build as well, and should do the right thing. Regards, Olivier
Re: Regexp
Hi. On 18/07/2018 13:10, Haim Ari wrote: Hello, Trying to set backend by regexp This regexp works outside of haproxy String: /1.0/manage/bu/ca?token=68bf68bf68bf68bf68bf=1212121212=123456789 Regexp: ^\/1\.0\/manage\/bu\/ca\?token=.*.segId=.*=123456789 What is the right syntax for this in haproxy ? I would use https://regex101.com/r/TjH7Ul/1/ ^\/1\.0\/manage\/bu\/ca\?token=(.*).segId=(.*).partner=123456789 and backref \1 \2 But that's just a wild guess as the information's from you are very small. Which version of haproxy (haproxy -vv)? Which use case do you have? http-request/http-response/acl/..? Some config snipped would also help a little bit ;-). Thank you Best regards Aleks
[PATCH] MINOR: Generate sha256 checksums in publish-release
Currently only md5 signatures are generated. While md5
still is not broken with regard to preimage attacks, sha256
clearly is the current secure solution.
This patch should be backported to all supported branches.
---
scripts/publish-release | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/scripts/publish-release b/scripts/publish-release
index ecef867b..6a615a6f 100755
--- a/scripts/publish-release
+++ b/scripts/publish-release
@@ -159,14 +159,15 @@ if [ -z "$AUTO" ]; then
fi
echo "Archiving sources for version $NEW ..."
-rm -f "${TARGET_DIR}/src${DEVEL}/haproxy-${NEW}.tar.gz"{,.md5}
+rm -f "${TARGET_DIR}/src${DEVEL}/haproxy-${NEW}.tar.gz"{,.md5,.sha256}
if ! git archive --format=tar --prefix="haproxy-${NEW}/" "v$NEW" | \
gzip -9 > "${TARGET_DIR}/src${DEVEL}/haproxy-${NEW}.tar.gz"; then
die "Failed to produce the tar.gz archive"
fi
( cd "$TARGET_DIR/src${DEVEL}" ; \
- md5sum haproxy-$NEW.tar.gz > haproxy-$NEW.tar.gz.md5 )
+ md5sum haproxy-$NEW.tar.gz > haproxy-$NEW.tar.gz.md5 ; \
+ sha256sum haproxy-$NEW.tar.gz > haproxy-$NEW.tar.gz.sha256 )
echo "Extracting doc ..."
git show "v$NEW:CHANGELOG" > "$TARGET_DIR/src/CHANGELOG"
@@ -178,6 +179,6 @@ done
echo "Done : ls -l ${TARGET_DIR}"
( cd "$TARGET_DIR" ;
- ls -l src/CHANGELOG "src${DEVEL}/haproxy-${NEW}".tar.gz{,.md5} $(for i in
"${DOC[@]}"; do echo "doc/${i#doc/}"{,.gz}; done)
+ ls -l src/CHANGELOG "src${DEVEL}/haproxy-${NEW}".tar.gz{,.md5,.sha256} $(for
i in "${DOC[@]}"; do echo "doc/${i#doc/}"{,.gz}; done)
)
echo
--
2.18.0
Re: Empty reply from server
On 18/07/2018 15:56, Serge Reynier wrote: Hi, We are having some issues recently when calling a specific url, we are getting the following error on the client side : * "Empty reply from server" I don't understand this statement: The problem is that Haproxy is not logging any of these errors, and more of that it shows a html 200 code. Do you have setuped logging in haproxy? Please can you share the config, thanks. Normally you should see 0 length in the haproxy http log. After some research, it seems that this error pops out because of bad headers returned by our code. So we would like to know if there's any way to log the "Empty reply from server" error on the haproxy side ? _/We are using Haproxy 1.8.12./_ Best regards, Serge. Best regards Aleks
Re: Suppression de l’extension
Hi. On 19/07/2018 15:09, -- wrote: Hello, Je souhaite supprimer l’extension présentée par mon serveur nginx mais depuis Haproxy Type A.com/index.html en A.com/index Est ce possible ? Maybe, but please can you ask in English, thanks. But let me try to interpret you question. reqrep ^([^\ :]*)\ /index.html \1\ /index https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#4.2-reqrep Merci Envoyé de mon iPhone Best regards Aleksg
Программа для создания планов пожарной эвакуации и проектов по видеонаблюдению и ОПС
Предлагаем Вашему вниманию программу для проектирования охранно-пожарных сигнализаций и систем видеонаблюдения, а так же создание планов пожарной эвакуации и меж этажных планов помещения, создание схем по подключению локальных сетей "sPlan.Проект" Можно закачать ее на флешку и носить всегда с собой. Не занимает много места, не требует установки и не дорого. Более 700 компаний уже по достоинству оценили возможности программы не упустите свой шанс. Цена на программу снижена на 20% Спешите! В библиотеке программы - 21 раздел, Общее количество символов в программе – 4600 шт. .www.plati.com/asp/pay.asp?idd=1997413 Программа SPlan.Проект позволят распечатывать сделанные чертежи и, при необходимости, экспортировать их файлы в форматы Windows Bitmap (с расширением .bmp), Graphics Interchange Format (.gif) и Enhanced Windows Metafile (*.emf). Это удобно для дальнейшей обработки чертежа (схемы), например, в полиграфии. Многие журналы и издательства принимают для публикации чертежи схем, выполненные в этих форматах.
Suppression de l’extension
Hello, Je souhaite supprimer l’extension présentée par mon serveur nginx mais depuis Haproxy Type A.com/index.html en A.com/index Est ce possible ? Merci Envoyé de mon iPhone
Re: Connections stuck in CLOSE_WAIT state with h2
Hi Milan, Janusz,
I suspect I managed to reliably trigger the issue you were facing and
found a good explanation for it. It is caused by unprocessed bytes at
the end of the H1 stream. I manage to reproduce it if I chain two layers
of haproxy with the last one sending stats. It does not happen with a
single layer, so the scheduling matters a lot (I think it's important
that the final CRLF is present in the same response packet as the final
chunk).
Could you please try the attached patch to see if you're on the same
issue ?
Thanks,
Willy
>From 00610960a196f01b6e6b549e29eb1cf2426d253a Mon Sep 17 00:00:00 2001
From: Willy Tarreau
Date: Thu, 19 Jul 2018 10:58:28 +0200
Subject: BUG/MEDIUM: h2: never leave pending data in the output buffer on
close
We currently don't process trailers on H2, but this has an impact : on
chunked HTTP/1 responses, we decide to emit the ES bit once we see the
0CRLF. From this point the stream switches to the CLOSED state, which
aborts processing of the remaining bytes. Thus the extra CRLF which ends
trailers is not processed and remains in the buffer. This prevents the
stream from being notified about end of transmission, which in turn keeps
the mux busy and prevents the connection from quitting.
The case of the trailers is not the root cause of this issue, though it
is what triggers it. The root cause is that upon error and/or close, once
we know we're not going to process any more data, we must absolutely flush
any remaining bytes from the output buffer, otherwise there is no way the
stream can quit. This is what this patch does.
It looks very likely related to the issues reported and debugged by
Janusz Dziemidowicz and Milan Petruzelka.
One way to reproduce it is to chain two proxies with the last one emitting
chunked data (typically using the stats page) :
global
stats socket /tmp/sock1 mode 666 level admin
stats timeout 1h
tune.ssl.default-dh-param 1024
tune.bufsize 16384
defaults
mode http
timeout connect 4s
timeout client 10s
timeout server 20s
listen px1
bind :4443 ssl crt rsa+dh2048.pem npn h2 alpn h2
server s1 127.0.0.1:4445
listen px2
bind : ssl crt rsa+dh2048.pem npn h2 alpn h2
bind :4445
stats uri /
Then use curl to fetch the stats through px1 :
curl --http2 -k "https://127.0.0.1:4443/;
When curl is sent to the first one, "show sess" issued to the CLI will
show a remaining session during the client timeout. When curl is aimed at
port (px2), there is no such remaining session.
This fix needs to be backported to 1.8.
---
src/mux_h2.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/src/mux_h2.c b/src/mux_h2.c
index 0d0101e..47df89e 100644
--- a/src/mux_h2.c
+++ b/src/mux_h2.c
@@ -3302,6 +3302,14 @@ static int h2s_frt_make_resp_data(struct h2s *h2s,
struct buffer *buf)
/* we may need to add END_STREAM */
/* FIXME: we should also detect shutdown(w) below, but how ? Maybe we
* could rely on the MSG_MORE flag as a hint for this ?
+*
+* FIXME: what we do here is not correct because we send end_stream
+* before knowing if we'll have to send a HEADERS frame for the
+* trailers. More importantly we're not consuming the trailing CRLF
+* after the end of trailers, so it will be left to the caller to
+* eat it. The right way to do it would be to measure trailers here
+* and to send ES only if there are no trailers.
+*
*/
if (((h1m->flags & H1_MF_CLEN) && !(h1m->curr_len - size)) ||
!h1m->curr_len || h1m->state >= HTTP_MSG_DONE)
@@ -3404,6 +3412,13 @@ static int h2_snd_buf(struct conn_stream *cs, struct
buffer *buf, int flags)
}
}
+ if (h2s->st >= H2_SS_ERROR) {
+ /* trim any possibly pending data after we close (extra CR-LF,
+* unprocessed trailers, abnormal extra data, ...)
+*/
+ bo_del(buf, buf->o);
+ }
+
/* RST are sent similarly to frame acks */
if (h2s->st == H2_SS_ERROR || h2s->flags & H2_SF_RST_RCVD) {
cs->flags |= CS_FL_ERROR;
--
1.7.12.1
