Re: [PATCH] BUG/MEDIUM: dns: Correctly use weight specified in SRV record
On Thu, Oct 17, 2019 at 5:35 AM Daniel Corbett wrote: > Hello, > > > In #48 it was reported that when using the server-template > > directive combined with an SRV record that HAProxy would > always set the weight to "1" regardless of what the SRV record > contains. > > It was found that in an attempt to force a minimum value of "1" > actually ended up forcing "1" in all situations. This was due to > an improper equation: ( x / 256 ) + 1 > > This patch should be backported to 1.8 and 1.9 > > > > Thanks, > > -- Daniel > > > Hi Daniel, Thanks for the patch, but I don't think it's accurate. What this part of the code aims to do is to "map" a DNS weight into an HAProxy weight. There is a ratio of 256 between both: DNS being in range "0-65535" and HAProxy in range "0-255". What your code does, is that it ignores any DNS weight above 256 and force them to 1... The only "bug" I can see here now is that a server's weight can never be 0. But nobody reported this as an issue yet. I'll check what question is asked into #48 and answer it. As a conclusion, please don't apply this patch. Baptiste
Re: [PATCH] BUG/MEDIUM: dns: Correctly use weight specified in SRV record
Hello, On 10/16/19 11:32 PM, Daniel Corbett wrote: This patch should be backported to 1.8 and 1.9 Sorry, I forgot to indicate that this should be backported to 2.0 also. Thanks, -- Daniel
[PATCH] BUG/MEDIUM: dns: Correctly use weight specified in SRV record
Hello,
In #48 it was reported that when using the server-template
directive combined with an SRV record that HAProxy would
always set the weight to "1" regardless of what the SRV record
contains.
It was found that in an attempt to force a minimum value of "1"
actually ended up forcing "1" in all situations. This was due to
an improper equation: ( x / 256 ) + 1
This patch should be backported to 1.8 and 1.9
Thanks,
-- Daniel
>From b9c2d037b0b3cf06a7908bcaa4949a29245574ca Mon Sep 17 00:00:00 2001
From: Daniel Corbett
Date: Wed, 16 Oct 2019 23:13:20 -0400
Subject: [PATCH] BUG/MEDIUM: dns: Use weight as specified in SRV record
In #48 it was reported that when using the server-template
directive combined with an SRV record that HAProxy would
always set the weight to "1" regardless of what the SRV record
contains.
It was found that in an attempt to force a minimum value of "1"
actually ended up forcing "1" in all situations. This was due to
an improper equation: ( x / 256) + 1
This patch should be backported to 1.8 and 1.9
---
src/dns.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/src/dns.c b/src/dns.c
index 0ce6e8302..8a71bd495 100644
--- a/src/dns.c
+++ b/src/dns.c
@@ -546,7 +546,12 @@ static void dns_check_dns_response(struct dns_resolution *res)
/* Make sure weight is at least 1, so
* that the server will be used.
*/
- ha_weight = item->weight / 256 + 1;
+ if (item->weight > 1 && item->weight <= 256) {
+ ha_weight = item->weight;
+ }
+ else {
+ ha_weight = 1;
+ }
if (srv->uweight != ha_weight) {
char weight[9];
@@ -593,7 +598,12 @@ static void dns_check_dns_response(struct dns_resolution *res)
/* Make sure weight is at least 1, so
* that the server will be used.
*/
-ha_weight = item->weight / 256 + 1;
+if (item->weight > 1 && item->weight <= 256) {
+ ha_weight = item->weight;
+}
+else {
+ ha_weight = 1;
+}
snprintf(weight, sizeof(weight), "%d", ha_weight);
server_parse_weight_change_request(srv, weight);
--
2.17.1
Re: HAproxy transparent proxy and IPv6
Hi, I did some more testing and found the reason why it didn't work: I have added the required ip cmds: post-up ip rule add fwmark 1 lookup 100 post-up ip route add local 0.0.0.0/0 dev lo table 100 post-up ip route add local ::/0 dev lo table 100 ip rule add fwmark 1 lookup 100 only adds the fwmark for IPv4 rule table... ip -6 rule add fwmark 1 lookup 100 did the trick. Maybe that helps somebody else in the future. The whole ip-up/down looks like this now: post-up ip rule add fwmark 1 lookup 100 post-up ip -6 rule add fwmark 1 lookup 100 post-up ip route add local 0.0.0.0/0 dev lo table 100 post-up ip -6 route add local ::/0 dev lo table 100 pre-down ip -6 route del local ::/0 dev lo table 100 pre-down ip route del local 0.0.0.0/0 dev lo table 100 pre-down ip -6 route del from all fwmark 1 lookup 100 pre-down ip route del from all fwmark 1 lookup 100 Thanks Philipp smime.p7s Description: S/MIME Cryptographic Signature
[PATCH] BUG/MINOR: sample: Make the `field` converter compatible with `-m found`
Previously an expression like:
path,field(2,/) -m found
always returned `true`.
Bug exists since the `field` converter exists. That is:
f399b0debfc6c7dc17c6ad503885c911493add56
The fix should be backported to 1.6+.
---
reg-tests/converter/field.vtc | 39 +++
src/sample.c | 2 +-
2 files changed, 40 insertions(+), 1 deletion(-)
create mode 100644 reg-tests/converter/field.vtc
diff --git a/reg-tests/converter/field.vtc b/reg-tests/converter/field.vtc
new file mode 100644
index 0..29608fe5b
--- /dev/null
+++ b/reg-tests/converter/field.vtc
@@ -0,0 +1,39 @@
+varnishtest "field converter Test"
+
+feature ignore_unknown_macro
+
+server s1 {
+ rxreq
+ txresp
+} -repeat 3 -start
+
+haproxy h1 -conf {
+defaults
+ mode http
+ timeout connect 1s
+ timeout client 1s
+ timeout server 1s
+
+frontend fe
+ bind "fd@${fe}"
+
+ requests
+ http-request set-var(txn.uri) path
+ http-response set-header Found %[var(txn.uri),field(3,/)] if {
var(txn.uri),field(3,/) -m found }
+
+ default_backend be
+
+backend be
+ server s1 ${s1_addr}:${s1_port}
+} -start
+
+client c1 -connect ${h1_fe_sock} {
+ txreq -url "/foo/bar/baz"
+ rxresp
+ expect resp.status == 200
+ expect resp.http.found == "bar"
+ txreq -url "/foo"
+ rxresp
+ expect resp.status == 200
+ expect resp.http.found == ""
+} -run
diff --git a/src/sample.c b/src/sample.c
index e2d96904e..98b5d573f 100644
--- a/src/sample.c
+++ b/src/sample.c
@@ -2137,7 +2137,7 @@ static int sample_conv_field(const struct arg *arg_p,
struct sample *smp, void *
/* Field not found */
if (field != arg_p[0].data.sint) {
smp->data.u.str.data = 0;
- return 1;
+ return 0;
}
found:
smp->data.u.str.data = end - start;
--
2.23.0
Re: Issue with HTX
Le 16/10/2019 à 08:48, GARDAIS Ionel a écrit : Hi Christopher, First : good news : I was not able to reproduce the issue with 2.1-dev2-e0f48a-88 and HTX enable. I guess e0f8dc576f62ace9ad1055ca068ab5d4f3a952aa was the culprit. To answer your questions and for others on the list : - The issue arose with H1 (H2 not enable) - It's the client who complained about a malformed payload thus it was unable to unmarshall datas into a valid object (it was the result of an API call). The message from the client is a short error message like "expecting [0-9a-fA-F] but got 0x4f" (note that 0x4f is not a constant and would vary from run to run) - To my understanding, the payload is chunk-encoded. Hi, Thanks to confirm. So it is indeed a problem of chunking fixed by the commit e0f8dc576. The patch was backported to 2.0 and 1.9. Thanks for your help, -- Christopher Faulet
