Re: MEDIUM: Adding upstream socks4 proxy support
Alec, Am 26.04.19 um 22:10 schrieb Alec Liu: > Here is the patch for adding upstream socks4 proxy support. > Please help to review it, thank you. > I can't comment on the technical side, but a few comments on the 'process' side: 1. You did not update the documentation yet (doc/configuration.txt) 2. The subsystem is missing from your commit message. It probably should be: MEDIUM: connection: Add socks4 support for upstream connections 3. The two commits should be merged into a single one. 4. Please mention the issue number in the commit message: 'See issue #82' Best regards Tim Düsterhus
reg-tests fail on FreeBSD 12.0
please have a look build script: https://github.com/chipitsine/haproxy-1/commit/6739f36463dc9e82eb65a9fa8353a42128403f0c build log (error): https://api.cirrus-ci.com/v1/task/5196617547251712/logs/main.log any idea ? thanks! Ilya Shipicin
MEDIUM: Adding upstream socks4 proxy support
Hi List, Willy, Here is the patch for adding upstream socks4 proxy support. Please help to review it, thank you. Regards, Alexander Liu 0002-MINOR-fix-some-typos-and-formating.patch Description: Binary data 0001-MEDIUM-Adding-upstream-socks4-proxy-support.patch Description: Binary data
Re: List operations: Auto responders
Willy, Am 26.04.19 um 21:20 schrieb Willy Tarreau: >> The List-Id header is fairly standard, I guess that happens >> automatically with any mailing list software. Any special headers on the >> other hand are possibly something different. Thank you for checking (and >> confirming I'm not alone with this issue). > > OK I found it, it was in customheaders. I've added > "X-Auto-Response-Suppress:OOF" to the x-mailing-list, list-id and > list-post that were already present. We'll see. > I can confirm that the header is present now, thanks. Best regards Tim Düsterhus
Re: List operations: Auto responders
On Fri, Apr 26, 2019 at 09:09:21PM +0200, Tim Düsterhus wrote: > Willy, > > Am 26.04.19 um 20:59 schrieb Willy Tarreau: > >> I'm growing increasingly annoyed by all those misconfigured Microsoft > >> Exchange mailservers that send me out-of-office autoresponders to my > >> mails on the list. Am I the only one experiencing this issue? Do they > >> automatically go into your spam folders? > > > > No you're not the only one, I'm used to manually delete them when I > > see them, they're very minor noise compared to the 2 thousands daily > > mails I receive and sort in my mbox :-) > > The sieve filters on my server neatly sort my email into several folders > so that my actual INBOX is only used for mail that does not fit any > other category which only happens every other day. But as these > auto-responders cannot be clearly identified based off their headers > they go into there as well which is annoying. I used to do that for more than 5 years until I realized I wasn't following linux development anymore because it's never the right moment to actively open list archives. So now I can quickly scan them, read what interests me and archive them. And at the end what remains are my own e-mails, a few spams and the auto-responders, which don't live long since my finger is never far from the D key. > >> I've googled a bit and it appears the they can be suppressed using an > >> > >> X-Auto-Response-Suppress:OOF > >> > >> header [1]. Is it possible to re-configure the mailing list software to > >> add this header? > > > > I can try to do it, as I'm pretty sure we already emit a header to name > > the list, I'll have a look. Thanks for the pointer! > > The List-Id header is fairly standard, I guess that happens > automatically with any mailing list software. Any special headers on the > other hand are possibly something different. Thank you for checking (and > confirming I'm not alone with this issue). OK I found it, it was in customheaders. I've added "X-Auto-Response-Suppress:OOF" to the x-mailing-list, list-id and list-post that were already present. We'll see. Cheers, Willy
Re: List operations: Auto responders
Willy, Am 26.04.19 um 21:08 schrieb Willy Tarreau: > It's funny that I just received one such message in response to my response, > with "X-Auto-Response-Suppress: All" in it, very likely set to avoid > looping. It's tempting to try with this one. Sadly I immediately remove > all of these so I don't have a collection to see what values are presented. > > Hmmm I'm wrong, there's the archive on the mail server itself. > > $ grep '^X-Auto-Response-Suppress:' archives-haproxy | sort|uniq -c|sort -nr > 34 X-Auto-Response-Suppress:OOF > 6 X-Auto-Response-Suppress: OOF,AutoReply > 2 X-Auto-Response-Suppress: All > > So apparently the "OOF" pattern you found indeed seems mostly used. > By specifically searching for 'OOF' I found this documentation from Microsoft [1]. OOF means 'out of office' (why isn't it OOO?) which make up the bulk of the autoreplies so I guess that one is a good starter to check how it works. [1] https://docs.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxcmail/ced68690-498a-4567-9d14-5c01f974d8b1 Best regards Tim Düsterhus
Re: List operations: Auto responders
Willy, Am 26.04.19 um 20:59 schrieb Willy Tarreau: >> I'm growing increasingly annoyed by all those misconfigured Microsoft >> Exchange mailservers that send me out-of-office autoresponders to my >> mails on the list. Am I the only one experiencing this issue? Do they >> automatically go into your spam folders? > > No you're not the only one, I'm used to manually delete them when I > see them, they're very minor noise compared to the 2 thousands daily > mails I receive and sort in my mbox :-) The sieve filters on my server neatly sort my email into several folders so that my actual INBOX is only used for mail that does not fit any other category which only happens every other day. But as these auto-responders cannot be clearly identified based off their headers they go into there as well which is annoying. >> I've googled a bit and it appears the they can be suppressed using an >> >> X-Auto-Response-Suppress:OOF >> >> header [1]. Is it possible to re-configure the mailing list software to >> add this header? > > I can try to do it, as I'm pretty sure we already emit a header to name > the list, I'll have a look. Thanks for the pointer! The List-Id header is fairly standard, I guess that happens automatically with any mailing list software. Any special headers on the other hand are possibly something different. Thank you for checking (and confirming I'm not alone with this issue). Best regards Tim Düsterhus
Re: List operations: Auto responders
On Fri, Apr 26, 2019 at 08:59:41PM +0200, Willy Tarreau wrote: > > I've googled a bit and it appears the they can be suppressed using an > > > > X-Auto-Response-Suppress:OOF > > > > header [1]. Is it possible to re-configure the mailing list software to > > add this header? > > I can try to do it, as I'm pretty sure we already emit a header to name > the list, I'll have a look. Thanks for the pointer! It's funny that I just received one such message in response to my response, with "X-Auto-Response-Suppress: All" in it, very likely set to avoid looping. It's tempting to try with this one. Sadly I immediately remove all of these so I don't have a collection to see what values are presented. Hmmm I'm wrong, there's the archive on the mail server itself. $ grep '^X-Auto-Response-Suppress:' archives-haproxy | sort|uniq -c|sort -nr 34 X-Auto-Response-Suppress:OOF 6 X-Auto-Response-Suppress: OOF,AutoReply 2 X-Auto-Response-Suppress: All So apparently the "OOF" pattern you found indeed seems mostly used. Willy
Re: [PATCH] MINOR: systemd: Make use of master socket in systemd unit
Patrick, Am 26.04.19 um 20:55 schrieb Patrick Hemmer: > One other consideration is a problem I've been looking to address, and > that's better reloads. Right now the systemd unit sends a signal for the > reload, but sending a signal gets no feedback on whether the reload > operation was successful or not. Have you checked that you are using Type=notify in your unit file? It uses systemd's sd_notify API to communicate the reload to systemd which should do what you are searching for. See this mailing list thread: https://www.mail-archive.com/haproxy@formilux.org/msg27874.html Best regards Tim Düsterhus
Re: [PATCH] MINOR: systemd: Make use of master socket in systemd unit
Hi Patrick, On Fri, Apr 26, 2019 at 02:55:30PM -0400, Patrick Hemmer wrote: > One other consideration is a problem I've been looking to address, and > that's better reloads. Right now the systemd unit sends a signal for the > reload, but sending a signal gets no feedback on whether the reload > operation was successful or not. > > I haven't thought about this a whole lot, but I'm thinking the way to > address it would be some sort of inquiry to the master process, which means > using the socket. So if the systemd unit file ensured that the master socket > is available, then ExecReload could be adjusted to use it and get > success/failure feedback. A very long time ago I wanted to make haproxy itself be usable as a CLI client. Nowadays with socat available everywhere it's pointless, but it could at least be used to give a few orders to the master like "reload", "stop" or any such thing. Just like you can reload squid using "squid -k reconfigure" if my memory serves me right. The advantage here is that it would require no other tool and would know its own protocol. Willy
Re: List operations: Auto responders
Hi Tim, On Fri, Apr 26, 2019 at 08:42:45PM +0200, Tim Düsterhus wrote: > Hi List, > Willy, > > I'm growing increasingly annoyed by all those misconfigured Microsoft > Exchange mailservers that send me out-of-office autoresponders to my > mails on the list. Am I the only one experiencing this issue? Do they > automatically go into your spam folders? No you're not the only one, I'm used to manually delete them when I see them, they're very minor noise compared to the 2 thousands daily mails I receive and sort in my mbox :-) > I've googled a bit and it appears the they can be suppressed using an > > X-Auto-Response-Suppress:OOF > > header [1]. Is it possible to re-configure the mailing list software to > add this header? I can try to do it, as I'm pretty sure we already emit a header to name the list, I'll have a look. Thanks for the pointer! Willy
Re: [PATCH] MINOR: systemd: Make use of master socket in systemd unit
*From:* Tim Düsterhus [mailto:t...@bastelstu.be] *Sent:* Friday, April 26, 2019, 14:30 EDT *To:* William Lallemand *Cc:* haproxy@formilux.org, w...@1wt.eu *Subject:* [PATCH] MINOR: systemd: Make use of master socket in systemd unit William, Am 26.04.19 um 14:56 schrieb William Lallemand: On Fri, Apr 26, 2019 at 12:15:37AM +0200, Tim Duesterhus wrote: [Service] -Environment="CONFIG=/etc/haproxy/haproxy.cfg" "PIDFILE=/run/haproxy.pid" +Environment="CONFIG=/etc/haproxy/haproxy.cfg" "PIDFILE=/run/haproxy.pid" "MASTER_SOCKET=/run/haproxy-master.sock" ExecStartPre=@SBINDIR@/haproxy -f $CONFIG -c -q -ExecStart=@SBINDIR@/haproxy -Ws -f $CONFIG -p $PIDFILE +ExecStart=@SBINDIR@/haproxy -Ws -S $MASTER_SOCKET -f $CONFIG -p $PIDFILE ExecReload=@SBINDIR@/haproxy -f $CONFIG -c -q In my opinion that's not a good idea to do it this way, because you can't disable the master CLI by unsetting the MASTER_SOCKET variable. It's probably better to have "-S /run/haproxy-master.sock" in an $OPTIONS variable at the end of the ExecStart line. I'm not sure whether this is better. Yes you can disable the socket more easily then, but you have to remember to add it back when editing the 'OPTIONS' variable. I believe it boils to to this question: Does the user usually want to run with the socket enabled or not? My guess is that most users want to have this socket (having is better than needing!), they might just want to move it to a different location rather than outright disabling it. During my tests it was only accessible to root, so there does not appear a security issue in the default configuration either. On an unrelated note: Debian patches the unit file to add in such a variable, called 'EXTRAOPTS': https://salsa.debian.org/haproxy-team/haproxy/blob/master/debian/patches/haproxy.service-use-environment-variables.patch So if we want to go the 'OPTIONS' variable path we might want to re-use that variable name. Any change will break their patch anyway so they definitely notice. Best regards Tim Düsterhus One other consideration is a problem I've been looking to address, and that's better reloads. Right now the systemd unit sends a signal for the reload, but sending a signal gets no feedback on whether the reload operation was successful or not. I haven't thought about this a whole lot, but I'm thinking the way to address it would be some sort of inquiry to the master process, which means using the socket. So if the systemd unit file ensured that the master socket is available, then ExecReload could be adjusted to use it and get success/failure feedback. -Patrick
Re: [PATCH] MINOR: systemd: Make use of master socket in systemd unit
William, Am 26.04.19 um 14:56 schrieb William Lallemand: > On Fri, Apr 26, 2019 at 12:15:37AM +0200, Tim Duesterhus wrote: >> [Service] >> -Environment="CONFIG=/etc/haproxy/haproxy.cfg" "PIDFILE=/run/haproxy.pid" >> +Environment="CONFIG=/etc/haproxy/haproxy.cfg" "PIDFILE=/run/haproxy.pid" >> "MASTER_SOCKET=/run/haproxy-master.sock" >> ExecStartPre=@SBINDIR@/haproxy -f $CONFIG -c -q >> -ExecStart=@SBINDIR@/haproxy -Ws -f $CONFIG -p $PIDFILE >> +ExecStart=@SBINDIR@/haproxy -Ws -S $MASTER_SOCKET -f $CONFIG -p $PIDFILE >> ExecReload=@SBINDIR@/haproxy -f $CONFIG -c -q > > In my opinion that's not a good idea to do it this way, because you can't > disable the master CLI by unsetting the MASTER_SOCKET variable. > > It's probably better to have "-S /run/haproxy-master.sock" in an $OPTIONS > variable at the end of the ExecStart line. > I'm not sure whether this is better. Yes you can disable the socket more easily then, but you have to remember to add it back when editing the 'OPTIONS' variable. I believe it boils to to this question: Does the user usually want to run with the socket enabled or not? My guess is that most users want to have this socket (having is better than needing!), they might just want to move it to a different location rather than outright disabling it. During my tests it was only accessible to root, so there does not appear a security issue in the default configuration either. On an unrelated note: Debian patches the unit file to add in such a variable, called 'EXTRAOPTS': https://salsa.debian.org/haproxy-team/haproxy/blob/master/debian/patches/haproxy.service-use-environment-variables.patch So if we want to go the 'OPTIONS' variable path we might want to re-use that variable name. Any change will break their patch anyway so they definitely notice. Best regards Tim Düsterhus
Re: [PATCH] MINOR: systemd: Make use of master socket in systemd unit
Hi Tim, On Fri, Apr 26, 2019 at 12:15:37AM +0200, Tim Duesterhus wrote: > [Service] > -Environment="CONFIG=/etc/haproxy/haproxy.cfg" "PIDFILE=/run/haproxy.pid" > +Environment="CONFIG=/etc/haproxy/haproxy.cfg" "PIDFILE=/run/haproxy.pid" > "MASTER_SOCKET=/run/haproxy-master.sock" > ExecStartPre=@SBINDIR@/haproxy -f $CONFIG -c -q > -ExecStart=@SBINDIR@/haproxy -Ws -f $CONFIG -p $PIDFILE > +ExecStart=@SBINDIR@/haproxy -Ws -S $MASTER_SOCKET -f $CONFIG -p $PIDFILE > ExecReload=@SBINDIR@/haproxy -f $CONFIG -c -q In my opinion that's not a good idea to do it this way, because you can't disable the master CLI by unsetting the MASTER_SOCKET variable. It's probably better to have "-S /run/haproxy-master.sock" in an $OPTIONS variable at the end of the ExecStart line. -- William Lallemand
Re: v1.9.6: Lua sample-fetch 'backend_select': unknown runtime error from [C] method 'dup'
On 26/04/2019 11:56, Christopher Faulet wrote:
Le 24/04/2019 à 15:51, Ignacio Lopez a écrit :
Hello,
After upgrading from 1.8.14 to 1.9.6 I've started to get: Lua
sample-fetch 'backend_select': unknown runtime error from [C] method
'dup'
The following is enough to make it trigger:
function backend_select(txn) {
local payload = txn.req:dup();
}
core.register_fetches("backend_select", backend_select)
I'm a bit lost of why this could be happening. I'm tempted to simply
switch to "local payload = txn.sf:req_body()" as I'm only interested
on the http body part to be fair, but I thought it would be
interesting to know what's causing this.
Hi Ignacio,
Since HAProxy 1.9, functions from the Channel class are forbidden for
LUA scripts called from HTTP proxies. See commit 3f829a4b7 [1]. So the
Channel.dup function only duplicate the request content, unlike
Channel.get or Channel.set. But it can't work with the HTX, the new
internal HTTP representation introduced in 1.9. The HTX is not the
default mode in 1.9, but it is on the 2.0. So, Channel.dup was forbidden
too, to avoid inconsistencies between the HTX and the legacy modes.
Using the sample fetch req_body() is a more reliable way to get the
request body.
[1] http://git.haproxy.org/?p=haproxy-1.9.git;a=commit;h=3f829a4b7
Hi Christopher,
thanks for the detailed explanation, I really appreciate it.
Best regards.
Re: v1.9.6: Lua sample-fetch 'backend_select': unknown runtime error from [C] method 'dup'
Le 24/04/2019 à 15:51, Ignacio Lopez a écrit :
Hello,
After upgrading from 1.8.14 to 1.9.6 I've started to get: Lua
sample-fetch 'backend_select': unknown runtime error from [C] method
'dup'
The following is enough to make it trigger:
function backend_select(txn) {
local payload = txn.req:dup();
}
core.register_fetches("backend_select", backend_select)
I'm a bit lost of why this could be happening. I'm tempted to simply
switch to "local payload = txn.sf:req_body()" as I'm only interested
on the http body part to be fair, but I thought it would be
interesting to know what's causing this.
Hi Ignacio,
Since HAProxy 1.9, functions from the Channel class are forbidden for
LUA scripts called from HTTP proxies. See commit 3f829a4b7 [1]. So the
Channel.dup function only duplicate the request content, unlike
Channel.get or Channel.set. But it can't work with the HTX, the new
internal HTTP representation introduced in 1.9. The HTX is not the
default mode in 1.9, but it is on the 2.0. So, Channel.dup was forbidden
too, to avoid inconsistencies between the HTX and the legacy modes.
Using the sample fetch req_body() is a more reliable way to get the
request body.
[1] http://git.haproxy.org/?p=haproxy-1.9.git;a=commit;h=3f829a4b7
--
Christopher Faulet
Re: [ANNOUNCE] haproxy-1.9.7
Hi Christopher. Am 26.04.2019 um 10:40 schrieb Christopher Faulet: > Le 26/04/2019 à 10:29, Aleksandar Lazic a écrit : >> >> THe new images are also available on docker hub. >> >> https://hub.docker.com/r/me2digital/haproxy19 >> https://hub.docker.com/r/me2digital/haproxy-19-boringssl >> >> With openssl 1.1.1b / Boringssl and prometheus-exporter. >> >> I don't see the exporter in the output of -vv as mentioned in the blog post >> https://www.haproxy.com/blog/haproxy-exposes-a-prometheus-metrics-endpoint/ >> >> The make line is this >> >> ### >> + make -C /usr/src/haproxy TARGET=linux2628 USE_PCRE=1 USE_OPENSSL=1 >> SSL_INC=/usr/local/openssl/include SSL_LIB=/usr/local/openssl/lib USE_ZLIB=1 >> USE_LINUX_SPLICE=1 USE_TFO=1 USE_PCRE_JIT=1 USE_LUA=1 USE_PTHREAD_PSHARED=1 >> USE_REGPARM=1 USE_GETADDRINFO=1 USE_THREAD=1 >> EXTRA_OBJS=contrib/prometheus-exporter/service-prometheus.o all install-bin >> make: Entering directory `/usr/src/haproxy' >> ... >> ### > > Hi Aleks, > > The Prometheus exporter was not backported in 1.9. The compilation doesn't > fail > because the EXTRA_OBJS variable only exists since the version 2.0-dev1 :) Oh yes, I have forgotten, living on the edge is sometimes confusing ;-) Time for haproxy-2 image ;-) Regards Aleks
Re: [ANNOUNCE] haproxy-1.9.7
Le 26/04/2019 à 10:29, Aleksandar Lazic a écrit : THe new images are also available on docker hub. https://hub.docker.com/r/me2digital/haproxy19 https://hub.docker.com/r/me2digital/haproxy-19-boringssl With openssl 1.1.1b / Boringssl and prometheus-exporter. I don't see the exporter in the output of -vv as mentioned in the blog post https://www.haproxy.com/blog/haproxy-exposes-a-prometheus-metrics-endpoint/ The make line is this ### + make -C /usr/src/haproxy TARGET=linux2628 USE_PCRE=1 USE_OPENSSL=1 SSL_INC=/usr/local/openssl/include SSL_LIB=/usr/local/openssl/lib USE_ZLIB=1 USE_LINUX_SPLICE=1 USE_TFO=1 USE_PCRE_JIT=1 USE_LUA=1 USE_PTHREAD_PSHARED=1 USE_REGPARM=1 USE_GETADDRINFO=1 USE_THREAD=1 EXTRA_OBJS=contrib/prometheus-exporter/service-prometheus.o all install-bin make: Entering directory `/usr/src/haproxy' ... ### Hi Aleks, The Prometheus exporter was not backported in 1.9. The compilation doesn't fail because the EXTRA_OBJS variable only exists since the version 2.0-dev1 :) -- Christopher Faulet
Re: [ANNOUNCE] haproxy-1.9.7
Am 25.04.2019 um 23:18 schrieb Christopher Faulet: > Hi, > > HAProxy 1.9.7 was released on 2019/04/25. It added 100 new commits after > version > 1.9.6. > > After a month since the last release, a huge number of bugs were addressed > into > this release. The most significant are fixes of 100% CPU usage issues. Olivier > and Willy worked hard on it. They fixed several bugs in the task scheduler and > improved it. Another issue concerned the streams and the way aborts was > handled. The flag reporting the abort on the stream-interface was cleared too > early. So the stream was not properly released, looping infinitely on > itself. Thanks to Maciej for helping Olivier investigating on this > issue. Finally, two bugs leading to a loop were fixed in the H2 multiplexer. > The > first one occurred when an incomplete frame was received and no more data was > available. The second one when the subscription to the send events was made > twice, which should never happen. This last issue was also able to lead to > random crashes. > > Willy, with the help of Maksim, fixed a locking problem in the round-robin LB > causing occasional crashes of HAProxy because of a divide by zero when the > next > server's position was computed. Willy also fixed an AB/BA locking issue in the > listener's accept code thanks to Olivier and his self-locked list. At the end, > all this part was reworked. The lock on the listener queue disappeared and the > accept code was significantly improved. As mentioned, Olivier implemented > self-locked lists. It is now safe to manipulate such lists with multiple > threads > without having to worry about concurrency issues. > > A very old bug on how HTTP sample fetches work was fixed. All HTTP sample > fetches were buggy because the channel used was chosen depending on the sample > direction and not on the keyword really used. The request channel was used > when > called during the request analysis and the response one was used when called > during the response analysis, regardless the sample really called. It could > cause a whole bunch of bugs, from undefined behavior because the data were > extracted from the wrong buffer to crash of HAProxy. > > Many bugs in the HTX part were fixed. The most significant was a problem of > data > corruption when an header was added while some data were already received. It > was addressed by defragmenting the HTX message. It is a quick and dirty fix, > waiting for a better solution. The TCP splicing was fixed in the H1 > multiplexer. The handling of the CONNECT method was refactored to work when h1 > and h2 are mixed (an h1 client sending requests to an h2 server or this > opposite). And finally, the option "http-tunnel" was deprecated in HTX. It is > still supported in legacy HTTP, but in HTX, this options is now ignored. > > Otherwise, as always, there was a bunch of bugfixes and changes here and > there. The most noticeable are: > >- A memory leak was fixed in the map converter. And now when a map file is > loaded, the default value is parsed only when it is present. This fixes > segfaults at parsing time when no default value is provided. > >- Pattern IDs are now assigned after checking the config validity. It > fixes a > bug where some map identifiers were not assigned (appearing as -1 in show > map). Thanks to Pavlos to report this bug. > >- Several bugs was fixed on the SPOE, mainly on the way fragmented frames > was > handled internally. > >- A bug was fixed in the peers. Peer sessions were not always cleanly reset > on release, resulting in a bad state for new sessions. In addition, the > CLI > command "show peers" was added. It dumps info about the peers configured > in > "peers" sections. > >- Nenad fixed a security issue in the TLS ticket key rotation. Whenever > HAProxy was reloaded with rotated keys, the resumption would be broken > for > previous encryption key. CVE-2019-11323 was assigned to this bug. > >- Build of HAProxy on AIX 5.1 was fixed. > >- Some small improvements were brought to the master-worker mode. The busy > polling was disabled on the master process to not waste a dedicated > processor on it. And an unambiguous status is now set on exit. > >- The global directive "set-dumpable" was added to enable core dumps. It's > always a pain to get a core dump when enabling user/group setting (which > disables the dumpable flag on Linux), when using a chroot and/or when > HAProxy is started by a service management tool which requires complex > operations to just raise the core dump limit. It becomes much easier to > retrieve a core file by using this new directive. Temporarily moving the > chroot to a user-writable place generally enough. > >- Missing locks was added in set-map and add-acl HTTP rules. > >- The multithreading mode is now enabled on wurlf. And it is now compatible > with
BUG/MEDIUM: spoe: arg len encoded in previous frag frame but len changed
Hi here
I'm come again : )
Fragmented arg will do fetch at every encode time, each fetch may get
different result if SMP_F_MAY_CHANGE, for example the fetch ,
but the length already encoded in first fragment of the frame, that will
cause SPOA decode failed and waste resources.
Best regards
From 342258c94fbe8ed146e8490fb80a2a7c40cb9075 Mon Sep 17 00:00:00 2001
From: Kevin Zhu
Date: Fri, 26 Apr 2019 14:00:01 +0800
Subject: [PATCH] BUG/MEDIUM: spoe: arg len encoded in previous frag frame but
len changed
Fragmented arg will do fetch at every encode time, each fetch may get
different result if SMP_F_MAY_CHANGE, for example res.payload, but
the length already encoded in first fragment of the frame, that will
cause SPOA decode failed and waste resources.
---
include/proto/spoe.h | 7 ---
include/types/spoe.h | 1 +
src/flt_spoe.c | 3 ++-
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/include/proto/spoe.h b/include/proto/spoe.h
index e5b3b4b..86328ad 100644
--- a/include/proto/spoe.h
+++ b/include/proto/spoe.h
@@ -121,7 +121,7 @@ spoe_decode_buffer(char **buf, char *end, char **str, uint64_t *len)
* many bytes has been encoded. If <*off> is zero at the end, it means that all
* data has been encoded. */
static inline int
-spoe_encode_data(struct sample *smp, unsigned int *off, char **buf, char *end)
+spoe_encode_data(unsigned int *len, struct sample *smp, unsigned int *off, char **buf, char *end)
{
char *p = *buf;
int ret;
@@ -185,15 +185,16 @@ spoe_encode_data(struct sample *smp, unsigned int *off, char **buf, char *end)
end);
if (ret == -1)
return -1;
+*len = chk->data;
}
else {
/* The sample has been fragmented, encode remaining data */
-ret = MIN(chk->data - *off, end - p);
+ret = MIN(*len - *off, end - p);
memcpy(p, chk->area + *off, ret);
p += ret;
}
/* Now update <*off> */
- if (ret + *off != chk->data)
+ if (ret + *off != *len)
*off += ret;
else
*off = 0;
diff --git a/include/types/spoe.h b/include/types/spoe.h
index a744cd7..0ab5d5a 100644
--- a/include/types/spoe.h
+++ b/include/types/spoe.h
@@ -323,6 +323,7 @@ struct spoe_context {
struct spoe_message *curmsg; /* SPOE message from which to resume encoding */
struct spoe_arg *curarg; /* SPOE arg in from which to resume encoding */
unsigned int curoff; /* offset in from which to resume encoding */
+ unsigned int len; /* length of need to be encode, for SMP_F_MAY_CHANGE data */
unsigned int flags; /* SPOE_FRM_FL_* */
} frag_ctx; /* Info about fragmented frames, valid on if SPOE_CTX_FL_FRAGMENTED is set */
diff --git a/src/flt_spoe.c b/src/flt_spoe.c
index 63d40a6..b1a8788 100644
--- a/src/flt_spoe.c
+++ b/src/flt_spoe.c
@@ -2182,6 +2182,7 @@ spoe_encode_message(struct stream *s, struct spoe_context *ctx,
list_for_each_entry(arg, >args, list) {
ctx->frag_ctx.curarg = arg;
ctx->frag_ctx.curoff = UINT_MAX;
+ ctx->frag_ctx.curlen = 0;
encode_argument:
if (ctx->frag_ctx.curoff != UINT_MAX)
@@ -2196,7 +2197,7 @@ spoe_encode_message(struct stream *s, struct spoe_context *ctx,
/* Fetch the argument value */
smp = sample_process(s->be, s->sess, s, dir|SMP_OPT_FINAL, arg->expr, NULL);
- ret = spoe_encode_data(smp, >frag_ctx.curoff, buf, end);
+ ret = spoe_encode_data(>frag_ctx.len, smp, >frag_ctx.curoff, buf, end);
if (ret == -1 || ctx->frag_ctx.curoff)
goto too_big;
}
--
2.7.4
