stable-bot: Bugfixes waiting for a release 2.2 (18), 2.1 (13), 2.0 (8), 1.8 (6)

2020-08-18 Thread stable-bot
Hi,

This is a friendly bot that watches fixes pending for the next haproxy-stable 
release!  One such e-mail is sent periodically once patches are waiting in the 
last maintenance branch, and an ideal release date is computed based on the 
severity of these fixes and their merge date.  Responses to this mail must be 
sent to the mailing list.


Last release 2.2.2 was issued on 2020-07-31.  There are currently 18 patches in 
the queue cut down this way:
- 1 MAJOR, first one merged on 2020-08-05
- 6 MEDIUM, first one merged on 2020-08-05
- 11 MINOR, first one merged on 2020-08-05

Thus the computed ideal release date for 2.2.3 would be 2020-08-19, which was 
within the last week.

Last release 2.1.8 was issued on 2020-07-31.  There are currently 13 patches in 
the queue cut down this way:
- 4 MEDIUM, first one merged on 2020-08-05
- 9 MINOR, first one merged on 2020-08-11

Thus the computed ideal release date for 2.1.9 would be 2020-09-04, which is in 
three weeks or less.

Last release 2.0.17 was issued on 2020-07-31.  There are currently 8 patches in 
the queue cut down this way:
- 4 MEDIUM, first one merged on 2020-08-05
- 4 MINOR, first one merged on 2020-08-11

Thus the computed ideal release date for 2.0.18 would be 2020-10-04, which is 
in seven weeks or less.

Last release 1.8.26 was issued on 2020-08-03.  There are currently 6 patches in 
the queue cut down this way:
- 2 MEDIUM, first one merged on 2020-08-05
- 4 MINOR, first one merged on 2020-08-03

Thus the computed ideal release date for 1.8.27 would be 2020-10-26, which is 
in ten weeks or less.

The current list of patches in the queue is:
 - 2.2   - MAJOR   : dns: disabled servers through SRV 
records never recover
 - 2.2   - MEDIUM  : ssl: fix the ssl-skip-self-issued-ca 
option
 - 1.8, 2.0  - MEDIUM  : mux-h2: Don't fail if nothing is 
parsed for a legacy chunk response
 - 2.2   - MEDIUM  : ssl: never generates the chain from 
the verify store
 - 2.0, 2.1, 2.2 - MEDIUM  : mux-h1: Refresh H1 connection timeout 
after a synchronous send
 - 2.0, 2.1, 2.2 - MEDIUM  : htx: smp_prefetch_htx() must always 
validate the direction
 - 2.1, 2.2  - MEDIUM  : ssl: memory leak of ocsp data at 
SSL_CTX_free()
 - 1.8, 2.0, 2.1, 2.2- MEDIUM  : map/lua: Return an error if a map 
is loaded during runtime
 - 2.1, 2.2  - MINOR   : arg: Fix leaks during arguments 
validation for fetches/converters
 - 1.8, 2.0, 2.1, 2.2- MINOR   : lua: Check argument type to 
convert it to IP mask in arg validation
 - 2.1, 2.2  - MINOR   : ssl: fix memory leak at OCSP loading
 - 2.0, 2.1, 2.2 - MINOR   : snapshots: leak of snapshots on 
deinit()
 - 1.8, 2.0, 2.1, 2.2- MINOR   : stats: use strncmp() instead of 
memcmp() on health states
 - 2.2   - MINOR   : ssl: ssl-skip-self-issued-ca requires 
>= 1.0.2
 - 2.1, 2.2  - MINOR   : lua: Duplicate map name to load it 
when a new Map object is created
 - 2.2   - MINOR   : spoa-server: fix size_t format printing
 - 1.8, 2.0, 2.1, 2.2- MINOR   : lua: Check argument type to 
convert it to IPv4/IPv6 arg validation
 - 1.8   - MINOR   : dns: ignore trailing dot
 - 2.1, 2.2  - MINOR   : converters: Store the sink in an arg 
pointer for debug() converter
 - 2.1, 2.2  - MINOR   : lua: Duplicate lua strings in sample 
fetches/converters arg array

-- 
The haproxy stable-bot is freely provided by HAProxy Technologies to help 
improve the quality of each HAProxy release.  If you have any issue with these 
emails or if you want to suggest some improvements, please post them on the 
list so that the solutions suiting the most users can be found.



[RFC PATCH] MEDIUM: Add support for if-none-match for cache responses

2020-08-18 Thread Tim Duesterhus
William,

find below a very dirty proof of concept patch for issue 821

https://github.com/haproxy/haproxy/issues/821

With the following example configuration:

listen fe
mode http
bind *:8080
http-request cache-use foo
http-response cache-store foo
server foo localhost:8081
frontend be
mode http
bind *:8081
http-request return content-type text/plain lf-string stuff hdr etag 
'"stuff"'
cache foo
total-max-size 4

I get a proper 304 Not Modified without any valgrind complaints for some manual
example requests:

$ http localhost:8080 'if-none-match: "stuff"'
HTTP/1.1 200 OK
content-length: 5
content-type: text/plain
etag: "stuff"

stuff

$ http localhost:8080 'if-none-match: "stuff"'
HTTP/1.1 304 Not Modified
age: 1
content-length: 5
content-type: text/plain
etag: "stuff"



$ http localhost:8080 'if-none-match: "stuff2"'
HTTP/1.1 200 OK
age: 3
content-length: 5
content-type: text/plain
etag: "stuff"

stuff

Before continuing cleaning this up and properly handling both strong and weak
ETags according to the RFC I'd like to have a first review to see whether I am
generally on the right track there or whether I am doing dumb stuff that will
cause issues under certain circumstances :-)

Best regards
Tim Düsterhus

Apply with `git am --scissors` to automatically cut the commit message.

-- >8 --
see GitHub issue #821
---
 src/cache.c | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/src/cache.c b/src/cache.c
index 533b902bf..b8802bb06 100644
--- a/src/cache.c
+++ b/src/cache.c
@@ -4,6 +4,8 @@
  * Copyright 2017 HAProxy Technologies
  * William Lallemand 
  *
+ * Copyright 2020 Tim Duesterhus 
+ *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
  * as published by the Free Software Foundation; either version
@@ -875,6 +877,7 @@ static void http_cache_io_handler(struct appctx *appctx)
unsigned int len;
size_t ret, total = 0;
 
+   req_htx = htxbuf(>buf);
res_htx = htxbuf(>buf);
total = res_htx->data;
 
@@ -899,15 +902,31 @@ static void http_cache_io_handler(struct appctx *appctx)
}
 
if (appctx->st0 == HTX_CACHE_HEADER) {
+   struct http_hdr_ctx inm_ctx = { .blk = NULL };
+   int etag_match = 0;
+
/* Headers must be dump at once. Otherwise it is an error */
len = first->len - sizeof(*cache_ptr) - appctx->ctx.cache.sent;
ret = htx_cache_dump_msg(appctx, res_htx, len, HTX_BLK_EOH);
-   if (!ret || (htx_get_tail_type(res_htx) != HTX_BLK_EOH) ||
-   !htx_cache_add_age_hdr(appctx, res_htx))
+   if (!ret || (htx_get_tail_type(res_htx) != HTX_BLK_EOH))
+   goto error;
+
+   if (http_find_header(req_htx, ist("if-none-match"), _ctx, 
0)) {
+   struct http_hdr_ctx etag_ctx = { .blk = NULL };
+   if (http_find_header(res_htx, ist("etag"), _ctx, 
0)) {
+   if (isteq(inm_ctx.value, etag_ctx.value)) {
+   etag_match = 1;
+   http_replace_res_status(res_htx, (const 
struct ist) IST("304"));
+   http_replace_res_reason(res_htx, (const 
struct ist) IST("Not Modified"));
+   }
+   }
+   }
+
+   if (!htx_cache_add_age_hdr(appctx, res_htx))
goto error;
 
/* Skip response body for HEAD requests */
-   if (si_strm(si)->txn->meth == HTTP_METH_HEAD)
+   if (si_strm(si)->txn->meth == HTTP_METH_HEAD || etag_match)
appctx->st0 = HTX_CACHE_EOM;
else
appctx->st0 = HTX_CACHE_DATA;
-- 
2.28.0




Re: [PATCH] MINOR: cache: Reject duplicate cache names

2020-08-18 Thread Willy Tarreau
Hi Tim,

On Tue, Aug 18, 2020 at 10:20:27PM +0200, Tim Duesterhus wrote:
> Using a duplicate cache name most likely is the result of a misgenerated
> configuration. There is no good reason to allow this, as the duplicate
> caches can't be referred to.
> 
> This commit resolves GitHub issue #820.
> 
> It can be argued whether this is a fix for a bug or not. I'm erring on the
> side of caution and marking this as a "new feature". It can be considered for
> backporting to 2.2, but for other branches the risk of accidentally breaking
> some working (but non-ideal) configuration might be too large.

All 3 patches merged. I also agree for not going too far on this one. In
addition, it reintroduces an O(N^2) lookup during config parsing (we had
some in the past in backend lookups and even N^3 in state file processing)
so while I'm generally not worried, I'd rather stay on the safe side by
making sure nobody accidently hits that by using hundreds of thousands of
cache instances on an older version :-)

Thanks!
Willy



[PATCH] DOC: cache: Use '' instead of '' in error message

2020-08-18 Thread Tim Duesterhus
When the cache name is left out in 'filter cache' the error message refers
to a missing ''. The name of the cache is called 'name' within the docs.

Adjust the error message for consistency.

The error message was introduced in 99a17a2d91f9044ea20bba6617048488aed80555.
This commit first appeared in 1.9, thus the patch must be backported to 1.9+.
---
 src/cache.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/cache.c b/src/cache.c
index 533b902bf..4f8d2e04a 100644
--- a/src/cache.c
+++ b/src/cache.c
@@ -1407,7 +1407,7 @@ parse_cache_flt(char **args, int *cur_arg, struct proxy 
*px,
 
/* Get the cache filter name.  point on "cache" keyword */
if (!*args[pos + 1]) {
-   memprintf(err, "%s : expects an  argument", args[pos]);
+   memprintf(err, "%s : expects a  argument", args[pos]);
goto error;
}
name = strdup(args[pos + 1]);
-- 
2.28.0




[PATCH] MEDIUM: cfgparse: Emit hard error on truncated lines

2020-08-18 Thread Tim Duesterhus
As announced within the emitted log message this is going to become a hard
error in 2.3. It's 2.3 time now, let's do this.

see 2fd5bdb439da29f15381aeb57c51327ba57674fc
---
 src/cfgparse.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/src/cfgparse.c b/src/cfgparse.c
index de82a9fd3..17db1fcae 100644
--- a/src/cfgparse.c
+++ b/src/cfgparse.c
@@ -1876,11 +1876,11 @@ next_line:
char *line = thisline;
 
if (missing_lf != -1) {
-   ha_warning("parsing [%s:%d]: Stray NUL character at 
position %d. "
-  "This will become a hard error in HAProxy 
2.3.\n",
-  file, linenum, (missing_lf + 1));
-   err_code |= ERR_WARN;
+   ha_alert("parsing [%s:%d]: Stray NUL character at 
position %d.\n",
+file, linenum, (missing_lf + 1));
+   err_code |= ERR_ALERT | ERR_FATAL;
missing_lf = -1;
+   break;
}
 
linenum++;
@@ -2086,10 +2086,9 @@ next_line:
}
 
if (missing_lf != -1) {
-   ha_warning("parsing [%s:%d]: Missing LF on last line, file 
might have been truncated at position %d. "
-  "This will become a hard error in HAProxy 2.3.\n",
-  file, linenum, (missing_lf + 1));
-   err_code |= ERR_WARN;
+   ha_alert("parsing [%s:%d]: Missing LF on last line, file might 
have been truncated at position %d.\n",
+file, linenum, (missing_lf + 1));
+   err_code |= ERR_ALERT | ERR_FATAL;
}
 
if (cs && cs->post_section_parser)
-- 
2.28.0




[PR] Prevent favicon.ico requests errors for stats page.

2020-08-18 Thread PR Bot
Dear list!

Author: zurikus 
Number of patches: 2

This is an automated relay of the Github pull request:
   Prevent favicon.ico requests errors for stats page.

Patch title(s): 
   Prevent favicon.ico requests for stats page
   Merge pull request #1 from zurikus/zurikus-patch-1

Link:
   https://github.com/haproxy/haproxy/pull/824

Edit locally:
   wget https://github.com/haproxy/haproxy/pull/824.patch && vi 824.patch

Apply locally:
   curl https://github.com/haproxy/haproxy/pull/824.patch | git am -

Description:
   Prevent favicon.ico requests errors for stats page.
   
   Haproxy
   stats page don't have a favicon.ico, but browsers make a request for
   it.
   This lead to errors during stats page requests:
   
   Aug
   18 08:46:41 somehost.example.net haproxy[1521534]: X.X.X.X:61403
   [18/Aug/2020:08:46:41.437] stats stats/ -1/-1/-1/-1/0 503 222 - - SC--
   2/2/0/0/0 0/0 "GET /favicon.ico HTTP/1.1"
   Aug 18 08:46:42
   somehost.example.net haproxy[1521534]: X.X.X.X:61403
   [18/Aug/2020:08:46:42.650] stats stats/ -1/-1/-1/-1/0 503 222 - - SC--
   2/2/0/0/0 0/0 "GET /favicon.ico HTTP/1.1"
   
   Patch provided set
   empty favicon.ico for haproxy stats page.

Instructions:
   This github pull request will be closed automatically; patch should be
   reviewed on the haproxy mailing list (haproxy@formilux.org). Everyone is
   invited to comment, even the patch's author. Please keep the author and
   list CCed in replies. Please note that in absence of any response this
   pull request will be lost.