Commit Graph

21757 Commits

Author SHA1 Message Date
Christopher Faulet
21a488e6f5 BUG/MINOR: http-htx: Normalized absolute URIs with an empty port
Thanks to the previous commit ("MINOR: http: Considere empty ports as valid
default ports"), empty ports are now considered as valid default ports. Thus,
absolute URIs with empty port should be normalized.

So now, the following URIs are normalized:

 http://example.com:/  --> http://example.com/
 https://example.com:/ --> https://example.com/

This patch depend on:

   * MINOR: h1: Consider empty port as invalid in authority for CONNECT
   * MINOR: http: Considere empty ports as valid default ports

It is a bug regarding the RFC3986. Technically, I may be backported as far
as 2.4. However, this must be discussed first. If backported, the commits
above must be backported too.

(cherry picked from commit e5dfe1169d)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-23 08:54:05 +01:00
Christopher Faulet
676acc6df6 REG-TESTS: http: Add more tests about authority/host matching
More tests were added to h1_host_normalization.vtc to be sure we are RF3986
compliant. Among other things, some tests with empty ports were added.

(cherry picked from commit 1c52121e6d)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-23 08:52:13 +01:00
Christopher Faulet
da01e59022 BUG/MINOR: h1: Replace authority validation to conform RFC3986
Except for CONNECT method, where a normalization is performed, we expected
to have an exact match between the authority and the host header value.
However it was too strict. Indeed, default port must be handled and the
matching must respect the RFC3986.

There is already a scheme based normalizeation performed on the URI later,
on the HTX message. And we cannot normalize the URI during H1 parsing to be
able to report proper errors on the original raw buffer. And a systematic
read-only normalization to validate the authority will consume CPU for only
few requests. At the end, we decided to perform extra-checks when the exact
match fails. Now, following authority/host are considered as equivalent:

  http:  domain.com <=> domain.com:80  <=> domain.com:
  https: domain.com <=> domain.com:443 <=> domain.com:

This patch depends on:

  * MINOR: h1: Consider empty port as invalid in authority for CONNECT
  * MINOR: http: Considere empty ports as valid default ports

It is a bug regarding the RFC3986. Technically, I may be backported as far
as 2.4. However, this must be discussed first. If it is backported, the
commits above must be backported too.

(cherry picked from commit e16ffb0383)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-23 08:52:13 +01:00
Christopher Faulet
81cde62d38 MINOR: http: Considere empty ports as valid default ports
In RFC3986#6.2.3, following URIs are considered as equivalent:

      http://example.com
      http://example.com/
      http://example.com:/
      http://example.com:80/

The third one is interristing because the port is empty and it is still
considered as a default port. Thus, http_get_host_port() does no longer
return IST_NULL when the port is empty. Now, a ist is returned, it points on
the first character after the colon (':') with a length of 0. In addition,
http_is_default_port() now considers an empty port as a default port,
regardless the scheme.

This patch must not be backported, if so, without the previous one ("MINOR:
h1: Consider empty port as invalid in authority for CONNECT").

(cherry picked from commit 99ade9e0da)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-23 08:52:13 +01:00
Christopher Faulet
976f02a45d MINOR: h1: Consider empty port as invalid in authority for CONNECT
For now, this change is useless because http_get_host_port() returns
IST_NULL when the port is empty. But this will change. For other methods,
empty ports are valid. But not for CONNECT method. To still return a
400-Bad-Request if a CONNECT is performed with an empty port, istlen() is
used to test the port, instead of isttest().

(cherry picked from commit 75348c2e8b)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-23 08:52:13 +01:00
Frédéric Lécaille
fa588b4cf1 BUG/MINOR: quic: Do not request h3 clients to close its unidirection streams
It is forbidden to request h3 clients to close its Control and QPACK unidirection
streams. If not, the client closes the connection with H3_CLOSED_CRITICAL_STREAM(0x104).
Perhaps this could prevent some clients as Chrome to come back for a while.

But at quic_conn level there is no mean to identify the streams for which we cannot
send STOP_SENDING frame. Such a possibility is even not mentionned in RFC 9000.
At this time there is no choice than stopping sending STOP_SENDING frames for
all the h3 unidirectional streams inspecting the ->app_opps quic_conn value.

Must be backported to 2.7 and 2.6.

(cherry picked from commit d18025eeef)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit d388f5132a08696a515419a71bc5f432707bba91)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-23 08:01:10 +01:00
Remi Tricot-Le Breton
4b3d716fc8 BUG/MINOR: jwt: Wrong return value checked
The wrong return value was checked, resulting in dead code and
potential bugs.

It should fix GitHub issue #2005.
This patch should be backported up to 2.5.

(cherry picked from commit a0658c3cf3)
Signed-off-by: William Lallemand <wlallemand@haproxy.org>
(cherry picked from commit 739996c80a847cd9572d3a4e4e418a7a38ddc2ff)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 10:58:00 +01:00
Willy Tarreau
115dbf374c BUILD: hpack: include global.h for the trash that is needed in debug mode
When building with -DDEBUG_HPACK, the trash is needed, but it's declared
in global.h.

This may be backported to all supported versions.

(cherry picked from commit 7d84439b48)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 57724cab01d54f50f0b97c86aa604df033b39fec)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:42:59 +01:00
Willy Tarreau
8672494bb6 BUG/MINOR: mux-h2: add missing traces on failed headers decoding
In case HPACK cannot be decoded, logs are emitted but there's no info
in the H2 traces, so let's add them.

This may be backported to all supported versions.

(cherry picked from commit 17c630b846)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 1b821886812e25c1a86be5f9861e7a2c6835e008)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:42:51 +01:00
Willy Tarreau
a627d15da2 BUG/MINOR: mux-h2: make sure to produce a log on invalid requests
As reported by Dominik Froehlich in github issue #1968, some H2 request
parsing errors do not result in a log being emitted. This is annoying
for debugging because while an RST_STREAM is correctly emitted to the
client, there's no way without enabling traces to find it on the
haproxy side.

After some testing with various abnormal requests, a few places were
found where logs were missing and could be added. In this case, we
simply use sess_log() so some sample fetch functions might not be
available since the stream is not created. But at least there will
be a BADREQ in the logs. A good eaxmple of this consists in sending
forbidden headers or header syntax (e.g. presence of LF in value).
Some quick tests can be done this way:

- protocol error (LF in value):
  curl -iv --http2-prior-knowledge -H "$(printf 'a:b\na')" http://0:8001/

- too large header block after decoding:
  curl -v --http2-prior-knowledge -H "a:$(perl -e "print('a'x10000)")"  -H "a:$(perl -e "print('a'x10000)")"  http://localhost:8001/

This should be backported where needed, most likely 2.7 and 2.6 at
least for a start, and progressively to other versions.

(cherry picked from commit f43f36da5b)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 5341eee2ffcbc24ea6b903f73e9781d1b074e40e)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:42:42 +01:00
Amaury Denoyelle
f71aaecd64 BUG/MINOR: h3: properly handle connection headers
Connection headers are not used in HTTP/3. As specified by RFC 9114, a
received message containing one of those is considered as malformed and
rejected. When converting an HTX message to HTTP/3, these headers are
silently skipped.

This must be backported up to 2.6. Note that assignment to <h3s.err>
must be removed on 2.6 as stream level error has been introduced in 2.7
so this field does not exist in 2.6 A connection error will be used
instead automatically.

(cherry picked from commit 8ad2669175)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 67229cc2833ade0fe366c099e19c992cf7065ade)
[cf: Assignment to <h3s.err> removed as expected]
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:42:00 +01:00
Willy Tarreau
7b27b7d06e BUG/MINOR: listener: close tiny race between resume_listener() and stopping
Pierre Cheynier reported a very rare race condition on soft-stop in the
listeners. What happens is that if a previously limited listener is
being resumed by another thread finishing an accept loop, and at the
same time a soft-stop is performed, the soft-stop will turn the
listener's state to LI_INIT, and once the listener's lock is released,
resume_listener() in the second thread will try to resume this listener
which has an fd==-1, yielding a crash in listener_set_state():

  FATAL: bug condition "l->rx.fd == -1" matched at src/listener.c:288

The reason is that resume_listener() only checks for LI_READY, but doesn't
consider being called with a non-initialized or a stopped listener. Let's
also make sure we don't try to ressuscitate such a listener there.

This will have to be backported to all versions.

(cherry picked from commit d1ebee1774)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 87a566b86d0e7c2af9c59ef1c6ba1681c3b4fd21)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:40:26 +01:00
Remi Tricot-Le Breton
4b9991f443 BUG/MINOR: ssl: Fix compilation with OpenSSL 1.0.2 (missing ECDSA_SIG_set0)
This function was introduced in OpenSSL 1.1.0. Prior to that, the
ECDSA_SIG structure was public.
This function was used in commit 5a8f02ae "BUG/MEDIUM: jwt: Properly
process ecdsa signatures (concatenated R and S params)".

This patch needs to be backported up to branch 2.5 alongside commit
5a8f02ae.

(cherry picked from commit bb35e1f5aa)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit a1958aad1de4e8df9504aefeae0f1b4631768ac9)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:39:37 +01:00
Remi Tricot-Le Breton
62f4f6b7dc BUG/MEDIUM: jwt: Properly process ecdsa signatures (concatenated R and S params)
When the JWT token signature is using ECDSA algorithm (ES256 for
instance), the signature is a direct concatenation of the R and S
parameters instead of OpenSSL's DER format (see section
3.4 of RFC7518).
The code that verified the signatures wrongly assumed that they came in
OpenSSL's format and it did not actually work.
We now have the extra step of converting the signature into a complete
ECDSA_SIG that can be fed into OpenSSL's digest verification functions.

The ECDSA signatures in the regtest had to be recalculated and it was
made via the PyJWT python library so that we don't end up checking
signatures that we built ourselves anymore.

This patch should fix GitHub issue #2001.
It should be backported up to branch 2.5.

(cherry picked from commit 5a8f02ae66)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit a54d925410dec56327a319691100f899c260a021)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:39:32 +01:00
Daniel Corbett
f070489425 DOC: config: fix "Address formats" chapter syntax
The section on "Address formats" doesn't provide the dot (.) after the
chapter numbers, which breaks parsing within the HTML converter.
This commit adds the dot (.) after each chapter within Section 11.

This should be backported to versions 2.4 and above.

(cherry picked from commit 86aac23e6b)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit a6538d3e628cef042905c8f631995ba387072045)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:39:26 +01:00
Paul Barnetta
1350488916 BUG/MINOR: mux-fcgi: Correctly set pathinfo
Existing logic for checking whether a regex subexpression for pathinfo
is matched results in valid matches being ignored and non-matches having
a new zero length string stored in params->pathinfo. This patch reverses
the logic so params->pathinfo is set when the subexpression is matched.

Without this patch the example configuration in the documentation:

	path-info ^(/.+\.php)(/.*)?$

does not result in PATH_INFO being sent to the FastCGI application, as
expected, when the second subexpression is matched (in which case both
pmatch[2].rm_so and pmatch[2].rm_eo will be non-negative integers).

This patch may be backported as far as 2.2, the first release that made
the capture of this second subexpression optional.

(cherry picked from commit 26a9ac5f2f)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 6e44c2220b6ea0dbf2a92bd7dfa062ed96d116d8)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:39:15 +01:00
Willy Tarreau
4291bfeb92 DOC: config: mention the missing "quic4@" and "quic6@" in protocol prefixes
These two variants were missing from the section on protocol prefixes.

(cherry picked from commit ed68240607)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 6c67ace9b625bc3026b648d066bc8c40c4f159f7)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:37:46 +01:00
Willy Tarreau
c1b5f61373 DOC: config: fix aliases for protocol prefixes "udp4@" and "udp6@"
It was mentioned that they are equivalent to "stream+ipv*@" while it's
the equivalent of "dgram+ipv*@".

(cherry picked from commit 24101f9ce7)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit d971ef3cdeeed2f24d6ef2f2cb1e60010837be07)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:37:26 +01:00
Willy Tarreau
398eea103e DOC: config: fix wrong section number for "protocol prefixes"
The socket type prefixes used to reference section "11.5.3" instead of
"11.3" for "protocol prefixes".

(cherry picked from commit d4c6fbe87e)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 41664236b7b8d1cc8ca146df0b4b8f41a362406f)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:36:59 +01:00
Willy Tarreau
dad6068c35 BUG/MINOR: listeners: fix suspend/resume of inherited FDs
FDs inherited from a parent process do not deal well with suspend/resume
since commit 59b5da487 ("BUG/MEDIUM: listener: never suspend inherited
sockets") introduced in 2.3. The problem is that we now report that they
cannot be suspended at all, and they return a failure. As such, if a new
process fails to bind and sends SIGTTOU to the previous process, that
one will notice the failure and instantly switch to soft-stop, leaving
no chance to the new process to give up later and signal its failure.

What we need to do, however, is to stop receiving new connections from
such inherited FDs, which just means that the FD must be unsubscribed
from the poller (and resubscribed later if finally it has to stay).
With this a new process can start on the already bound FD without
problem thanks to the absence of polling, and when the old process
stops the new process will be alone on it.

This may be backported as far as 2.4.

(cherry picked from commit 64763342aa)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 0f6663b9acce9a9fbeafbac3a56f17fbab0b741c)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:36:45 +01:00
Willy Tarreau
b2817a3bdc BUG/MINOR: http-ana: make set-status also update txn->status
Patrick Hemmer reported an interesting case where the status present in
the logs doesn't reflect what was reported to the user. During analysis
we could figure that it was in fact solely caused by the code dealing
with the set-status action. Indeed, set-status does update the status
in the HTX message itself but not in the HTTP transaction. However, at
most places where the status is needed to take a decision, it is
retrieved from the transaction, and the logs proceed like this as well,
though the "status" sample fetch function does retrieve it from the HTX
data. This particularly means that once a set-status has been used to
modify the status returned to the user, logs do not match that status,
and the response code distribution doesn't match either. However a
subsequent rule using the status as a condition will still match because
the "status" sample fetch function does also extract the status from the
HTX stream. Here's an example that fails:

  frontend f
    bind :8001
    mode http
    option httplog
    log stdout daemon
    http-after-response set-status 400

This will return a 400 to the client but log a 503 and increment
http_rsp_5xx.

In the end the root cause is that we need to make txn->status the only
authoritative place to get the status, and as such it must be updated
by the set-status rule. Ideally "status" should just use txn->status
but with the two synchronized this way it's not needed.

This should be backported since it addresses some consistency issues
between logs and what's observed. The set-status action appeared in
1.9 so all stable versions are eligible.

(cherry picked from commit 640e253698)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 87c1d795d7e9299d374a7ef9c6beda5e3bbea354)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:36:39 +01:00
Christopher Faulet
365cd65b68 BUG/MINOR: http-fetch: Don't block HTTP sample fetch eval in HTTP_MSG_ERROR state
It was inherited from the legacy HTTP mode, but the message parsing is
handled by the underlying mux now. Thus, if a message is in HTTP_MSG_ERROR
state, it is just an analysis error and not a parsing error. So there is no
reason to block the HTTP sample fetch evaluation in this case.

This patch could be backported in all stable versions (For the 2.0, only the
htx part must be updated).

(cherry picked from commit 5aab0a30c5)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 6efffd09cff6da32986eef24711ab7e23204c59c)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:36:14 +01:00
Christopher Faulet
751e1ec219 BUG/MINOR: http-ana: Report SF_FINST_R flag on error waiting the request body
When we wait for the request body, we are still in the request analysis. So
a SF_FINST_R flag must be reported in logs. Even if some data are already
received, at this staged, nothing is sent to the server.

This patch could be backported in all stable versions.

(cherry picked from commit f4569bbcc1)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit ec4df6f9668b601e2775b28d6b1250ac37a5f26c)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:36:00 +01:00
Christopher Faulet
1101a0504f BUG/MINOR: promex: Don't forget to consume the request on error
When the promex applet triggers an error, for instance because the URI is
invalid, we must still take care to consume the request. Otherwise, the
error will be handled by HTTP analyzers as a server abort.

This patch must be backported as far as 2.0.

(cherry picked from commit c1b013bc61)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit f40463aea88b1af63f2967ae311546af70fd72e8)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:35:55 +01:00
Willy Tarreau
8910e078f1 BUG/MEDIUM: peers: make "show peers" more careful about partial initialization
Since 2.6 with commit 34e4085f8 ("MEDIUM: peers: Balance applets across
threads") the initialization of a peers appctx may be postponed with a
wakeup, causing some partially initialized appctx to be visible. The
"show peers" command used to only care about peers without appctx, but
now it must also take care of those with no stconn, otherwise it can
occasionally crash while dumping them.

This fix must be backported to 2.6. Thanks to Patrick Hemmer for
reporting the problem.

(cherry picked from commit 03926129b0)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 546bda683e042924c10f6d870fd42aa6580cd6aa)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:35:51 +01:00
Christopher Faulet
ba582b85a5 BUG/MINOR: resolvers: Wait the resolution execution for a do_resolv action
The do_resolv action triggers a resolution and must wait for the
result. Concretely, if no cache entry is available, it creates a resolution
and wakes up the resolvers task. Then it yields. When the action is
recalled, if the resolution is still running, it yields again.

However, if the resolution is not running, it does not check it was
running. Thus, it is possible to ignore the resolution because the action
was recalled before the resolvers task had a chance to be executed. If there
is result, the action must yield.

This patch should fix the issue #1993. It must be backported as far as 2.0.

(cherry picked from commit 51dbb4cb79)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 4283282a61370c3ae406aa7a9e300c0ed1116f4c)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:35:40 +01:00
Christopher Faulet
c79c7f4912 BUG/MINOR: hlua: Fix Channel.line and Channel.data behavior regarding the doc
These both functions are buggy and don't respect the documentation. They
must wait for more data, if possible.

For Channel.data(), it must happen if not enough data was received orf if no
length was specified and no data was received. The first case is properly
handled but not the second one. An empty string is return instead. In
addition, if there is no data and the channel can't receive more data, 'nil'
value must be returned.

In the same spirit, for Channel.line(), we must try to wait for more data
when no line is found if not enough data was received or if no length was
specified. Here again, only the first case is properly handled. And for this
function too, 'nil' value must be returned if there is no data and the
channel can't receive more data.

This patch is related to the issue #1993. It must be backported as far as
2.5.

(cherry picked from commit 0ae2e63d85)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 08554a4669b92f4d6c988a7dd4fd318c9e8ec903)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:35:36 +01:00
Christopher Faulet
48bb2f41aa BUG/MINOR: h1-htx: Remove flags about protocol upgrade on non-101 responses
It is possible to have an "upgrade:" header and the corresponding value in
the "connection:" header for a non-101 response. It happens for
426-Upgrade-Required messages. However, on HAProxy side, a parsing error is
reported for this kind of message because no websocket key header
("sec-websocket-accept:") is found in the response.

So a possible fix could be to not perform this test for non-101
responses. However, having flags about protocol upgrade on this kind of
response could lead to other bugs. Instead, corresponding flags are
removed. Thus, during the H1 response post-parsing, H1_MF_CONN_UPG and
H1_MF_UPG_WEBSOCKET flags are removed from any non-101 response.

This patch should fix the issue #1997. It must be backported as far as 2.4.

(cherry picked from commit 5f36bfe42e)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit b4784965cbcc2b914477a8a47be52cbf6803b62d)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:35:29 +01:00
Amaury Denoyelle
8260e7902b MINOR: mux-quic: add traces for flow-control limit reach
Add new traces when QUIC flow-control limits are reached at stream or
connection level. This may help to explain an interrupted transfer.

This should be backported up to 2.6.

(cherry picked from commit 31d2057c59)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 7e32f314bcd3e101e59fd3c32d77d6b31e9dd578)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:35:14 +01:00
Amaury Denoyelle
61aea88729 BUG/MINOR: mux-quic: fix transfer of empty HTTP response
QUIC stream did not transferred its response if it was an empty HTTP
response without headers nor entity body. This is caused by an
incomplete condition on qc_send() which skips streams with empty
<tx.buf>.

Fix this by extending the condition. Sending will be conducted on a
stream if <tx.buf> is not empty or FIN notification must be provided.
This allows to send the last STREAM frame for this stream.

Such HTTP responses should be extremely rare so this bug is labelled as
MINOR. It was encountered with a HTTP/0.9 request on an empty payload.
The bug was triggered as HTTP/0.9 does not support header in response
message.

Also, note that condition to wakeup MUX tasklet has been changed
similarly in qc_send_buf(). It is not mandatory to work properly
however, most probably because another tasklet_wakeup() is done
before/after.

This should be backported up to 2.6.

(cherry picked from commit ab6cdecd71)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit f85eae7f4c30d896537d46c2691c790f0f0c0efc)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:35:11 +01:00
William Lallemand
83d0d0f425 DOC: management: add details about @system-ca in "show ssl ca-file"
Explain why @system-ca is seen in "show ssl ca-file".

Should fix issue #1979.

Can be backported till 2.6.

(cherry picked from commit f29c4155a8)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit f51c1076f811f3968d2b05a4751d5dafd4d6d61b)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:35:06 +01:00
William Lallemand
54727f77aa DOC: management: add details on "Used" status
Add details on the "Used" status of the "show crl/ca-file/cert" CLI
command.

Could be backported in every branch till 2.5.

Should fix issue #1979.

(cherry picked from commit 0c39526dab)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 741bc5cac9f36c6ac74a8b6248ba1217a26cbf55)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:35:00 +01:00
Manu Nicolas
8012c2c812 CLEANUP: htx: fix a typo in an error message of http_str_to_htx
This fixes a typo in an error message about headers in the
http_str_to_htx function.

(cherry picked from commit 45b6b23335)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit bfddb2aae3841fd27cbe999d247e05ddf6465684)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:34:44 +01:00
Remi Tricot-Le Breton
23db8c664b BUG/MINOR: http: Memory leak of http redirect rules' format string
When the configuration contains such a line:
    http-request redirect location /
a "struct logformat_node" object is created and it contains an "arg"
member which gets alloc'ed as well in which we copy the new location
(see add_to_logformat_list). This internal arg pointer was not freed in
the dedicated release_http_redir release function.
Likewise, the expression pointer was not released as well.

This patch can be backported to all stable branches. It should apply
as-is all the way to 2.2 but it won't on 2.0 because release_http_redir
did not exist yet.

(cherry picked from commit 3120284c29)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit fe5f84ae3eddbfbb34b1fd9b08b50c6246358279)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:34:34 +01:00
Aurelien DARRAGON
0c34554950 REGTEST: fix the race conditions in hmac.vtc
A "Connection: close" header is added to responses to avoid any connection
reuse. This should avoid any "HTTP header incomplete" errors.

(cherry picked from commit 7956aa14d3)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 1b767f6b82388e90c9cfe2098a87461a1206c73c)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:34:22 +01:00
Aurelien DARRAGON
387aa39763 REGTEST: fix the race conditions in digest.vtc
A "Connection: close" header is added to responses to avoid any connection
reuse. This should avoid any "HTTP header incomplete" errors.

(cherry picked from commit 1858c244c4)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit d40737e2cf0ddeac4711bf27d798714b573f2605)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:34:18 +01:00
Aurelien DARRAGON
7866b5ca33 REGTEST: fix the race conditions in add_item.vtc
A "Connection: close" header is added to responses to avoid any connection
reuse. This should avoid any "HTTP header incomplete" errors.

(cherry picked from commit 63762b05b0)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 924f2406a9663ec8dd3de377abc19e7844b19c5c)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:34:15 +01:00
Aurelien DARRAGON
77bc9f1f24 REGTEST: fix the race conditions in json_query.vtc
A "Connection: close" header is added to responses to avoid any connection
reuse. This should avoid any "HTTP header incomplete" errors.

(cherry picked from commit d4140a79c5)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 35195396dad3af26f8e42126a0c5a789669c498e)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:34:12 +01:00
Aurelien DARRAGON
3fcf827712 BUG/MINOR: proxy: free orgto_hdr_name in free_proxy()
Unlike fwdfor_hdr_name, orgto_hdr_name was not properly freed in
free_proxy().

This did not cause observable memory leaks because originalto proxy option is
only used for user configurable proxies, which are solely freed right before
process termination.
No backport needed unless some architectural changes causing regular proxies
to be freed and reused multiple times within single process lifetime are made.

(cherry picked from commit b2d797a53f)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 545f8a12c46174f50ddf6dfe0c8b1b3f379b12c2)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:34:05 +01:00
Christopher Faulet
ff7ada7d7a DOC: config: remove duplicated "http-response sc-set-gpt0" directive
This directive was erroneously duplicated.

This patch could be backported as far as 2.5.

(cherry picked from commit 39055d159f)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit aac8110c4465a4d1aa5cb8c992fd6ce8f8bd3aa2)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:33:42 +01:00
Christopher Faulet
32616807a9 DOC: config: fix alphabetical ordering of http-after-response rules
The 'capture' action must be placed after the 'allow' action.

This patch could be backported as far as 2.5.

(cherry picked from commit d9d36b8b6b)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 47192fe67fb71fd27ef4f9c9d3427aa706462051)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:33:38 +01:00
Christopher Faulet
d02e1170f8 BUG/MAJOR: buf: Fix copy of wrapping output data when a buffer is realigned
There is a bug in b_slow_realign() function when wrapping output data are
copied in the swap buffer. block1 and block2 sizes are inverted. Thus blocks
with a wrong size are copied. It leads to data mixin if the first block is
in reality larger than the second one or to a copy of data outside the
buffer is the first block is smaller than the second one.

The bug was introduced when the buffer API was refactored in 1.9. It was
found by a code review and seems never to have been triggered in almost 5
years. However, we cannot exclude it is responsible of some unresolved bugs.

This patch should fix issue #1978. It must be backported as far as 2.0.

(cherry picked from commit 61aded057d)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 4a048c13f5ec3bcd060c8af955fe51694400b69d)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:33:34 +01:00
Christopher Faulet
5df4953f8d BUG/MINOR: http-fetch: Only fill txn status during prefetch if not already set
When an HTTP sample fetch is evaluated, a prefetch is performed to check the
channel contains a valid HTTP message. If the HTTP analysis was not already
started, some info are filled.

It may be an issue when an error is returned before the response analysis
and when http-after-response rules are used because the original HTTP txn
status may be crushed. For instance, with the following configuration:

  listen l1
    log global
    mode http
    bind :8000

    log-format ST=%ST
    http-after-response set-status 400
    #http-after-response set-var(res.foo) status

A "ST=503" is reported in the log messages, independantly on the first
http-after-response rule. The same must happen if the second rule is
uncommented. However, for now, a "ST=400" is logged.

To fix the bug, during the prefetch, the HTTP txn status is only set if it
is undefined (-1). This way, we are sure the original one is never lost.

This patch should be backported as far as 2.2.

(cherry picked from commit 31850b470a)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit a9f36628395b012cef7f9efddaf90954b68ff167)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:33:28 +01:00
Willy Tarreau
d5036411eb BUG/MINOR: stick-table: report the correct action name in error message
sc-inc-gpc() learned to use arrays in 2.5 with commit 4d7ada8f9 ("MEDIUM:
stick-table: add the new arrays of gpc and gpc_rate"), but the error
message says "sc-set-gpc" instead of "sc-inc-gpc". Let's fix this to
avoid confusion.

This can be backported to 2.5.

(cherry picked from commit 20391519c3)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 59bf319279b1457c6f01b160764e79c27a5808c9)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:31:40 +01:00
Willy Tarreau
039e90dcc6 BUILD: makefile: sort the features list
The features list that appears in -vv appears in a random order, which
always makes it a pain to look for certain features. Let's sort it.

(cherry picked from commit 848362f2d2)
[wt: applied to Makefile]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit a99f189732d6f2c1c2e99cf39d4b3a17b4e040c8)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:31:00 +01:00
Willy Tarreau
161ba95c0f BUILD: makefile: build the features list dynamically
The BUILD_FEATURES string was created too early to inherit implicit
additions. This could make the features list report that some features
were disabled while they had later been enabled. Better make it a macro
that is interpreted where needed based on the current state of each
option.

(cherry picked from commit 39d6c34837)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 650959acbecc2a607629fd905a39e0689a02ec92)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:30:55 +01:00
Amaury Denoyelle
ba2817bba8 BUG/MINOR: mux-quic: ignore remote unidirectional stream close
Remove ABORT_NOW() on remote unidirectional stream closure. This is
required to ensure our implementation is evolutive enough to not fail on
unknown stream type.

Note that for the moment MAX_STREAMS_UNI flow-control frame is never
emitted. This should be unnecessary for HTTP/3 which have a limited
usage of unidirectional streams but may be required if other application
protocols are supported in the future.

ABORT_NOW() was triggered by s2n-quic which opens an unknown
unidirectional stream with greasing. This was detected by QUIC interop
runner for http3 testcase.

This must be backported up to 2.6.

(cherry picked from commit 9107731358)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 1ac095486711084895763fe026bd9186f3415bd6)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:30:22 +01:00
Christopher Faulet
a6ff9f5361 BUG/MINOR: pool/stats: Use ullong to report total pool usage in bytes in stats
The same change was already performed for the cli. The stats applet and the
prometheus exporter are also concerned. Both use the stats API and rely on
pool functions to get total pool usage in bytes. pool_total_allocated() and
pool_total_used() must return 64 bits unsigned integer to avoid any wrapping
around 4G.

This may be backported to all versions.

(cherry picked from commit c960a3b60f)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit b174d82dff11d7fb67e9a7f53c20a658f23dd9e7)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:29:07 +01:00
Christopher Faulet
84f5cba24f BUG/MEDIUM: mux-h2: Refuse interim responses with end-stream flag set
As state in RFC9113#8.1, HEADERS frame with the ES flag set that carries an
informational status code is malformed. However, there is no test on this
condition.

On 2.4 and higher, it is hard to predict consequences of this bug because
end of the message is only reported with a flag. But on 2.2 and lower, it
leads to a crash because there is an unexpected extra EOM block at the end
of an interim response.

Now, when a ES flag is detected on a HEADERS frame for an interim message, a
stream error is sent (RST_STREAM/PROTOCOL_ERROR).

This patch should solve the issue #1972. It should be backported as far as
2.0.

(cherry picked from commit 827a6299e6)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit ebfae006c6b5de1d1fe0cdd51847ec1e39d5cf59)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:29:00 +01:00
Amaury Denoyelle
b118355b00 BUG/MEDIUM: mux-quic: fix double delete from qcc.opening_list
qcs instances for bidirectional streams are inserted in
<qcc.opening_list>. It is removed from the list once a full HTTP request
has been parsed. This is required to implement http-request timeout.

In case a stream is deleted before receiving full HTTP request, it also
must be removed from <qcc.opening_list>. This was not the case on first
implementation but has been fixed by the following patch :
  641a65ff3c
  BUG/MINOR: mux-quic: remove qcs from opening-list on free

This means that now a stream can be deleted from the list in two
different functions. Sadly, as LIST_DELETE was used in both cases,
nothing prevented a double-deletion from the list, even though
LIST_INLIST was used. Both calls are replaced with LIST_DEL_INIT which
is idempotent.

This bug causes memory corruption which results in most cases in a
segfault, most of times outside of mux-quic code itself. It has been
found first by gabrieltz who reported it on the github issue #1903. Big
thanks to him for his testing.

This bug also causes failures on several 'M' transfer testcase of QUIC
interop-runner. The s2n-quic client is particularly useful in this case
as segfaults triggers were most of the times on the LIST_DELETE
operation itself. This is probably due to its encapsulating of HEADERS
frame with fin bit delayed in a following empty STREAM frame.

This must be backported wherever the above patch is, up to 2.6.

(cherry picked from commit 15337fd808)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 151737fa818ffb37c8eb1706ef16722b6dd68f8b)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
2023-01-20 09:28:16 +01:00