IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
In github issue #1878, Bart Butler reported observing turn-around states
(1 second pause) after connection retries going to different servers,
while this ought not happen.
In fact it does happen because back_handle_st_cer() enforces the TAR
state for any algo that's not round-robin. This means that even leastconn
has it, as well as hashes after the number of servers changed.
Prior to doing that, the call to stream_choose_redispatch() has already
had a chance to perform the correct choice and to check the algo and
the number of retries left. So instead we should just let that function
deal with the algo when needed (and focus on deterministic ones), and
let the former just obey. Bart confirmed that the fixed version works
as expected (no more delays during retries).
This may be backported to older releases, though it doesn't seem very
important. At least Bart would like to have it in 2.4 so let's go there
for now after it has cooked a few weeks in 2.6.
(cherry picked from commit 406efb96d135efe1d5a85bf58c589f7b6dbd8c70)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Idle connections do not work on 32-bit machines due to an alignment issue
causing the connection nodes to be indexed with their lower 32-bits set to
zero and the higher 32 ones containing the 32 lower bitss of the hash. The
cause is the use of ebmb_node with an aligned data, as on this platform
ebmb_node is only 32-bit aligned, leaving a hole before the following hash
which is a uint64_t:
$ pahole -C conn_hash_node ./haproxy
struct conn_hash_node {
struct ebmb_node node; /* 0 20 */
/* XXX 4 bytes hole, try to pack */
int64_t hash; /* 24 8 */
struct connection * conn; /* 32 4 */
/* size: 40, cachelines: 1, members: 3 */
/* sum members: 32, holes: 1, sum holes: 4 */
/* padding: 4 */
/* last cacheline: 40 bytes */
};
Instead, eb64 nodes should be used when it comes to simply storing a
64-bit key, and that is what this patch does.
For backports, a variant consisting in simply marking the "hash" member
with a "packed" attribute on the struct also does the job (tested), and
might be preferable if the fix is difficult to adapt. Only 2.6 and 2.5
are affected by this.
(cherry picked from commit 852234848241f61a976f8856123a34a3c19275ba)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
The httpclient does support DNS resolution since 2.6.
Must be backported to 2.6.
(cherry picked from commit 9ae05bb1e082577858e9f51e04f8ef0c7cb25383)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Calling the function with an offset when "offset + len" was superior or equal
to the targeted blk length caused 'v' value to be improperly set.
And because 'v' is directly provided to htx_replace_blk_value(), blk consistency was compromised.
(It seems that blk was overrunning in htx_replace_blk_value() due to
this and header data was overwritten in this case).
This patch adds the missing checks to make the function behave as
expected when offset is set and offset+len is greater or equals to the targeted blk length.
Some comments were added to the function as well.
It may be backported to 2.6 and 2.5
(cherry picked from commit bcbcf98e0c0149f91365f1f2d207be018124f6f2)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
hlua_http_msg_insert_data() function is called upon
HTTPMessage.insert() method from lua script.
This function did not work properly for multiple reasons:
- An incorrect argument check was performed and prevented the user
from providing optional offset argument.
- Input and output variables were inverted
and offset was not handled properly. The same bug
was also fixed in hlua_http_msg_del_data(), see:
'BUG/MINOR: hlua: fixing hlua_http_msg_del_data behavior'
The function now behaves as described in the documentation.
This could be backported to 2.6 and 2.5.
(cherry picked from commit 7fdba0ae544cb1b14b7d3864b06f38c752505094)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
GH issue #1885 reported that HTTPMessage.remove() did not
work as expected.
It turns out that underlying hlua_http_msg_del_data() function
was not working properly due to input / output inversion as well
as incorrect user offset handling.
This patch fixes it so that the behavior is the one described in
the documentation.
This could be backported to 2.6 and 2.5.
(cherry picked from commit d7c71b03d83144913a33a09080c3738b27395af8)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
To avoid any UAF when a resolution is released, a mechanism was added to
abort a resolution and delayed the released at the end of the current
execution path. This mechanism depends on an hard assumption: Any reference
on an aborted resolution must be removed. So, when a resolution is aborted,
it is removed from the resolver lists and inserted into a death row list.
However, a resolution may still be referenced in the query_ids tree. It is
the tree containing all resolutions with a pending request. Because aborted
resolutions are released outside the resolvers lock, it is possible to
release a resolution on a side while a query ansswer is received and
processed on another one. Thus, it is still possible to have a UAF because
of this bug.
To fix the issue, when a resolution is aborted, it is removed from any list,
but it is also removed from the query_ids tree.
This patch should solve the issue #1862 and may be related to #1875. It must
be backported as far as 2.2.
(cherry picked from commit eaabf060312f6aad1c0c195ad33e5ea612acc47a)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
If stream_new() fails after the frontend SC is attached, the underlying SE
descriptor is not properly reset. Among other things, SE_FL_ORPHAN flag is
not set again. Because of this error, a BUG_ON() is triggered when the mux
stream on the frontend side is destroyed.
Thus, now, when stream_new() fails, SE_FL_ORPHAN flag is set on the SE
descriptor and its stream-connector is set to NULL.
This patch should solve the issue #1880. It must be backported to 2.6.
(cherry picked from commit 3ab72c66a01ca81aa93cf1f0bd29430db8271792)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
The frontend SC is attached before the backend one is allocated. Thus an
allocation error on backend SC must be handled before an error on the
frontend SC.
This patch must be backported to 2.6.
(cherry picked from commit 4cfc038cb19996f5d2fe60284fdb556503a5f9ef)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Because memprintf return an error to the caller and not on screen.
the function which perform display of message on the right output
is in charge of adding \n if it is necessary.
This patch may be backported.
(cherry picked from commit 70e38e91b41c3446cd6d7993dd71fe6100996fa3)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
The s1 server is acting like a SMTP server. But it sends two CRLF at the end of
each line, while only one CRLF must be returned. It only works becaue both CRLF
are received at the same time.
(cherry picked from commit 330af2d7ed2d8d72800fc7761253ff6965681742)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Released version 2.6.6 with the following main changes :
- MEDIUM: peers: limit the number of updates sent at once
- MINOR: Revert part of clarifying samples support per os commit
- BUILD: makefile: enable crypt(3) for NetBSD
- BUG/MINOR: quic: Retransmitted frames marked as acknowledged
- BUG/MINOR: quic: Possible crash with "tls-ticket-keys" on QUIC bind lines
- BUG/MINOR: h1: Support headers case adjustment for TCP proxies
- BUG/MINOR: quic: Possible crash when verifying certificates
- BUILD: quic: add some ifdef around the SSL_ERROR_* for libressl
- BUILD: ssl: fix ssl_sock_switchtx_cbk when no client_hello_cb
- BUILD: quic: temporarly ignore chacha20_poly1305 for libressl
- BUILD: quic: enable early data only with >= openssl 1.1.1
- BUILD: ssl: fix the ifdef mess in ssl_sock_initial_ctx
- BUILD: quic: fix the #ifdef in ssl_quic_initial_ctx()
- MINOR: quic: add QUIC support when no client_hello_cb
- MINOR: quic: Add traces about sent or resent TX frames
- MINOR: quic: No TRACE_LEAVE() in retrieve_qc_conn_from_cid()
- BUG/MINOR: quic: Wrong connection ID to thread ID association
- BUG/MINOR: task: always reset a new tasklet's call date
- BUG/MINOR: task: make task_instant_wakeup() work on a task not a tasklet
- MINOR: task: permanently enable latency measurement on tasklets
- CLEANUP: task: rename ->call_date to ->wake_date
- BUG/MINOR: task: Fix detection of tasks profiling in tasklet_wakeup_after()
- BUG/MINOR: sched: properly account for the CPU time of dying tasks
- MINOR: sched: store the current profile entry in the thread context
- BUG/MINOR: stream/sched: take into account CPU profiling for the last call
- BUG/MINOR: signals/poller: set the poller timeout to 0 when there are signals
- BUG/MINOR: quic: Speed up the handshake completion only one time
- BUG/MINOR: quic: Trace fix about packet number space information.
- BUG/MINOR: h3: Crash when h3 trace verbosity is "minimal"
- MINOR: h3: Add the quic_conn object to h3 traces
- MINOR: h3: Missing connection argument for a TRACE_LEAVE() argument
- MINOR: h3: Send the h3 settings with others streams (requests)
- BUG/MINOR: signals/poller: ensure wakeup from signals
- CI: cirrus-ci: bump FreeBSD image to 13-1
- DEV: flags: fix usage message to reflect available options
- DEV: flags: add missing CO_FL_FDLESS connection flag
- BUG/MEDIUM: proxy: ensure pause_proxy() and resume_proxy() own PROXY_LOCK
- MINOR: listener: small API change
- MINOR: proxy/listener: support for additional PAUSED state
- BUG/MINOR: stats: fixing stat shows disabled frontend status as 'OPEN'
- CLEANUP: pollers: remove dead code in the polling loop
- BUG/MINOR: mux-h1: Increment open_streams counter when H1 stream is created
- REGTESTS: healthcheckmail: Relax matching on the healthcheck log message
- CLEANUP: listener: function comment typo in stop_listener()
- BUG/MINOR: listener: null pointer dereference suspected by coverity
- REGTESTS: log: test the log-forward feature
- BUG/MEDIUM: sink: bad init sequence on tcp sink from a ring.
- REGTESTS: ssl/log: test the log-forward with SSL
- DOC: fix TOC in starter guide for subsection 3.3.8. Statistics
- MEDIUM: quic: separate path for rx and tx with set_encryption_secrets
- BUG/MEDIUM: mux-quic: fix crash on early app-ops release
- CLEANUP: mux-quic: remove stconn usage in h3/hq
- BUG/MINOR: mux-quic: do not remotely close stream too early
- BUG/MEDIUM: server: segv when adding server with hostname from CLI
- CLEANUP: quic,ssl: fix tiny typos in C comments
- BUG/MEDIUM: captures: free() an error capture out of the proxy lock
- BUILD: fd: fix a build warning on the DWCAS
- SCRIPTS: announce-release: update some URLs to https
- BUG/MEDIUM: mux-quic: fix nb_hreq decrement
- BUG/MINOR: mux-quic: do not keep detached qcs with empty Tx buffers
- REORG: mux-quic: extract traces in a dedicated source file
- REORG: mux-quic: export HTTP related function in a dedicated file
- MINOR: mux-quic: refactor snd_buf
- BUG/MEDIUM: mux-quic: properly trim HTX buffer on snd_buf reset
- REGTESTS: ssl: adopt tests to OpenSSL-3.0.N
- REGTESTS: ssl: adopt tests to OpenSSL-3.0.N
- REGTESTS: ssl: fix grep invocation to use extended regex in ssl_generate_certificate.vtc
- BUG/MINOR: log: improper behavior when escaping log data
Patrick Hemmer reported an improper log behavior when using
log-format to escape log data (+E option):
Some bytes were truncated from the output:
- escape_string() function now takes an extra parameter that
allow the caller to specify input string stop pointer in
case the input string is not guaranteed to be zero-terminated.
- Minors checks were added into lf_text_len() to make sure dst
string will not overflow.
- lf_text_len() now makes proper use of escape_string() function.
This should be backported as far as 1.8.
(cherry picked from commit c5bff8e550cf49b0cb3a7abb998b2c915323eca9)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
in 2f2a2884b7464ccb56469cb94d8a1ae4015a8cb6 grep should have use regex flag -E, but flag
was lost by mistake
(cherry picked from commit b6189bc268255b799a77fdffcaaa7b221ca2d7a9)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
on Ubuntu-22.04 openssl-3.0.5 is shipped which has changed ec curve
description to "Server Temp Key: ECDH, secp384r1, 384 bits"
(cherry picked from commit 2f2a2884b7464ccb56469cb94d8a1ae4015a8cb6)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
on Ubuntu-22.04 openssl-3.0.5 is shipped which has changed ec curve
description to "Server Temp Key: ECDH, prime256v1, 256 bits"
(cherry picked from commit 0865160b93b1ac8326ac0e5b57be24504070c2c1)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
MUX QUIC snd_buf operation whill return early if a qcs instance is
resetted. In this case, HTX is left untouched and the callback returns
the whole bufer size. This lead to an undefined behavior as the stream
layer is notified about a transfer but does not see its HTX buffer
emptied. In the end, the transfer may stall which will lead to a leak on
session.
To fix this, HTX buffer is now resetted when snd_buf is short-circuited.
This should fix the issue as now the stream layer can continue the
transfer until its completion.
This patch has already been tested by Tristan and is reported to solve
the github issue #1801.
This should be backported up to 2.6.
(cherry picked from commit 0ed617ac2ff377ce60bd9c8fd97fd9da32d43971)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Factorize common code between h3 and hq-interop snd_buf operation. This
is inserted in MUX QUIC snd_buf own callback.
The h3/hq-interop API has been adjusted to directly receive a HTX
message instead of a plain buf. This led to extracting part of MUX QUIC
snd_buf in qmux_http module.
This should be backported up to 2.6.
(cherry picked from commit 9534e59bb9057cfa5762f9c119579a67f705de37)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Extract function dealing with HTX outside of MUX QUIC. For the moment,
only rcv_buf stream operation is concerned.
The main objective is to be able to support both TCP and HTTP proxy mode
with a common base and add specialized modules on top of it.
This should be backported up to 2.6.
(cherry picked from commit d80fbcaca266696a7d6de7342876d104c42e91e9)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
QUIC MUX implements several APIs to interface with stream, quic-conn and
app-ops layers. It is planified to better separate this roles, possibly
by using several files.
The first step is to extract QUIC MUX traces in a dedicated source
files. This will allow to reuse traces in multiple files.
The main objective is to be
able to support both TCP and HTTP proxy mode with a common base and add
specialized modules on top of it.
This should be backported up to 2.6.
(cherry picked from commit 36d50bff22563ba650918ccedaa695fcb6b8fa3e)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
A qcs instance free may be postponed in stream detach operation if the
stream is not locally closed. This condition is there to achieve
transfering data still present in Tx buffer. Once all data have been
emitted to quic-conn layer, qcs instance can be released.
However, the stream is only closed locally if HTX EOM has been seen or
it has been resetted. In case the transfer finished without EOM, a
detached qcs won't be freed even if there is no more activity on it.
This bug was not reproduced but was found on code analysis. Its precise
impact is unknown but it should not cause any leak as all qcs instances
are freed with its parent qcc connection : this should eventually happen
on MUX timeout or QUIC idle timeout.
To adjust this, condition to mark a stream as locally closed has been
extended. On qcc_streams_sent_done() notification, if its Tx buffer has
been fully transmitted, it will be closed if either FIN STREAM was set
or the stream is detached.
This must be backported up to 2.6.
(cherry picked from commit 3dc4e5a5b947aa55b65a6bde17bbce331586894b)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
nb_hreq is a counter on qcc for active HTTP requests. It is incremented
for each qcs where a full HTTP request was received. It is decremented
when the stream is closed locally :
- on HTTP response fully transmitted
- on stream reset
A bug will occur if a stream is resetted without having processed a full
HTTP request. nb_hreq will be decremented whereas it was not
incremented. This will lead to a crash when building with
DEBUG_STRICT=2. If BUG_ON_HOT are not active, nb_hreq counter will wrap
which may break the timeout logic for the connection.
This bug was triggered on haproxy.org. It can be reproduced by
simulating the reception of a STOP_SENDING frame instead of a STREAM one
by patching qc_handle_strm_frm() :
+ if (quic_stream_is_bidi(strm_frm->id))
+ qcc_recv_stop_sending(qc->qcc, strm_frm->id, 0);
+ //ret = qcc_recv(qc->qcc, strm_frm->id, strm_frm->len,
+ // strm_frm->offset.key, strm_frm->fin,
+ // (char *)strm_frm->data);
To fix this bug, a qcs is now flagged with a new QC_SF_HREQ_RECV. This
is set when the full HTTP request is received. When the stream is closed
locally, nb_hreq will be decremented only if this flag was set.
This must be backported up to 2.6.
(cherry picked from commit afb7b9d8e5a70a741bbb890945fa9ff51dad027d)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Some components like Discourse were already redirecting to https. Other
ones like docs and git are covered by the certificate, and finally
switching the advertised scheme for www should increase the ratio of
H2 and H3 in the stats (resp 8.9 and 1.9%) and possibly help spot new
issues.
(cherry picked from commit 68b3e135e36ddb17a6b2643c7af938226705f713)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Ilya reported in issue #1816 a build warning on armhf (promoted to error
here since -Werror):
src/fd.c: In function fd_rm_from_fd_list:
src/fd.c:209:87: error: passing argument 3 of __ha_cas_dw discards volatile qualifier from pointer target type [-Werror=discarded-array-qualifiers]
209 | unlikely(!_HA_ATOMIC_DWCAS(((long *)&fdtab[fd].update), (uint32_t *)&cur_list.u32, &next_list.u32))
| ^~~~~~~~~~~~~~
This happens only on such an architecture because the DWCAS requires the
pointer not the value, and gcc seems to be needlessly picky about reading
a const from a volatile! This may safely be backported to older versions.
(cherry picked from commit 85af76070412d87433fbcaa0ac95833a8470159d)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Ed Hein reported in github issue #1856 some occasional watchdog panics
in 2.4.18 showing extreme contention on the proxy's lock while the libc
was in malloc()/free(). One cause of this problem is that we call free()
under the proxy's lock in proxy_capture_error(), which makes no sense
since if we can free the object under the lock after it's been detached,
we can also free it after releasing the lock (since it's not referenced
anymore).
This should be backported to all relevant versions, likely all
supported ones.
(cherry picked from commit da9f25875958757fd1f16b74bd887977e78c8b09)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
This fixes 4 tiny and harmless typos in mux_quic.c, quic_tls.c and
ssl_sock.c. Originally sent via GitHub PR #1843.
Signed-off-by: cui fliter <imcusg@gmail.com>
[Tim: Rephrased the commit message]
[wt: further complete the commit message]
(cherry picked from commit a94bedc0de218e784683e52ba669912b6cc71741)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
When calling 'add server' with a hostname from the cli (runtime),
str2sa_range() does not resolve hostname because it is purposely
called without PA_O_RESOLVE flag.
This leads to 'srv->addr_node.key' being NULL. According to Willy it
is fine behavior, as long as we handle it properly, and is already
handled like this in srv_set_addr_desc().
This patch fixes GH #1865 by adding an extra check before inserting
'srv->addr_node' into 'be->used_server_addr'. Insertion and removal
will be skipped if 'addr_node.key' is NULL.
It must be backported to 2.6 and 2.5 only.
(cherry picked from commit 8d0ff284064e7a47ae46897e0ce9b08abe539315)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
A stream is considered as remotely closed once we have received all the
data with the FIN bit set.
The condition to close the stream was wrong. In particular, if we
receive an empty STREAM frame with FIN bit set, this would have close
the stream even if we do not have yet received all the data. The
condition is now adjusted to ensure that Rx buffer contains all the data
up to the stream final size.
In most cases, this bug is harmless. However, if compiled with
DEBUG_STRICT=2, a BUG_ON_HOT crash would have been triggered if close is
done too early. This was most notably the case sometimes on interop test
suite with quinn or kwik clients. This can also be artificially
reproduced by simulating reception of an empty STREAM frame with FIN bit
set in qc_handle_strm_frm() :
+ if (strm_frm->fin) {
+ qcc_recv(qc->qcc, strm_frm->id, 0,
+ strm_frm->len, strm_frm->fin,
+ (char *)strm_frm->data);
+ }
ret = qcc_recv(qc->qcc, strm_frm->id, strm_frm->len,
strm_frm->offset.key, strm_frm->fin,
(char *)strm_frm->data);
This must be backported up to 2.6.
(cherry picked from commit d1310f8d327b7102558e8c549ce09e4925b1824b)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Small cleanup on snd_buf for application protocol layer.
* do not export h3_snd_buf
* replace stconn by a qcs argument. This is better as h3/hq-interop only
uses the qcs instance.
This should be backported up to 2.6.
(cherry picked from commit 8d4ac48d3def189190c29b6f1f5d697b180f7e30)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
H3 SETTINGS emission has recently been delayed. The idea is to send it
with the first STREAM to reduce sendto syscall invocation. This was
implemented in the following patch :
3dd79d378c86b3ebf60e029f518add5f1ed54815
MINOR: h3: Send the h3 settings with others streams (requests)
This patch works fine under nominal conditions. However, it will cause a
crash if a HTTP/3 connection is released before having sent any data,
for example when receiving an invalid first request. In this case,
qc_release will first free qcc.app_ops HTTP/3 application protocol layer
via release callback. Then qc_send is called to emit any closing frames
built by app_ops release invocation. However, in qc_send, as no data has
been sent, it will try to complete application layer protocol
intialization, with a SETTINGS emission for HTTP/3. Thus, qcc.app_ops is
reused, which is invalid as it has been just freed. This will cause a
crash with h3_finalize in the call stack.
This bug can be reproduced artificially by generating incomplete HTTP/3
requests. This will in time trigger http-request timeout without any
data send. This is done by editing qc_handle_strm_frm function.
- ret = qcc_recv(qc->qcc, strm_frm->id, strm_frm->len,
+ ret = qcc_recv(qc->qcc, strm_frm->id, strm_frm->len - 1,
strm_frm->offset.key, strm_frm->fin,
(char *)strm_frm->data);
To fix this, application layer closing API has been adjusted to be done
in two-steps. A new shutdown callback is implemented : it is used by the
HTTP/3 layer to generate GOAWAY frame in qc_release prologue.
Application layer context qcc.app_ops is then freed later in qc_release
via the release operation which is now only used to liberate app layer
ressources. This fixes the problem as the intermediary qc_send
invocation will be able to reuse app_ops before it is freed.
This patch fixes the crash, but it would be better to adjust H3 SETTINGS
emission in case of early connection closing : in this case, there is no
need to send it. This should be implemented in a future patch.
This should fix the crash recently experienced by Tristan in github
issue #1801.
This must be backported up to 2.6.
(cherry picked from commit f8aaf8bdfa40e21b1a2f600c3ed6455bf9b6a763)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
With quicTLS the set_encruption_secrets callback is always called with
the read_secret and the write_secret.
However this is not the case with libreSSL, which uses the
set_read_secret()/set_write_secret() mecanism. It still provides the
set_encryption_secrets() callback, which is called with a NULL
parameter for the write_secret during the read, and for the read_secret
during the write.
The exchange key was not designed in haproxy to be called separately for
read and write, so this patch allow calls with read or write key to
NULL.
(cherry picked from commit 95fc737fc6edfa2575ce982b739184e99475c215)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
This subsection has been moved from 3.4.9 to 3.3.8 somewhere along
2.4, but the TOC has not been updated - resulting in a invalid
anchor in the HTML version.
Needs to be backported to 2.4+
(cherry picked from commit 243c2d18221b36b087ad9c177293306119f3fafd)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Test the log-forward section with an SSL server and an SSL bind.
Must be backported as far as 2.3.
(cherry picked from commit 23bc0b20bd82c983bccb289825c6024730aaf405)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
The init of tcp sink, particularly for SSL, was done
too early in the code, during parsing, and this can cause
a crash specially if nbthread was not configured.
This was detected by William using ASAN on a new regtest
on log forward.
This patch adds the 'struct proxy' created for a sink
to a list and this list is now submitted to the same init
code than the main proxies list or the log_forward's proxies
list. Doing this, we are assured to use the right init sequence.
It also removes the ini code for ssl from post section parsing.
This patch should be backported as far as v2.2
Note: this fix uses 'goto' labels created by commit
'BUG/MAJOR: log-forward: Fix log-forward proxies not fully initialized'
but this code didn't exist before v2.3 so this patch needs to be
adapted for v2.2.
(cherry picked from commit d6e581de4be1d3564d771056303242c9ae930c40)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
This reg-test test the log-forward feature by chaining a UDP and a TCP
log-forwarder.
It could be backported as far as 2.3.
(cherry picked from commit ebf600a8384040a023b5278c1005ee1a2c04d712)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Please refer to GH #1859 for more info.
Coverity suspected improper proxy pointer handling.
Without the fix it is considered safe for the moment, but it might not
be the case in the future as we want to keep the ability to have
isolated listeners.
Making sure stop_listener(), pause_listener(), resume_listener()
and listener_release() functions make proper use
of px pointer in that context.
No need for backport except if multi-connection protocols (ie:FTP)
were to be backported as well.
(cherry picked from commit a57786e87d0746baec43ea888bf6cd30c490d2fb)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
A minor typo related to stop_listener() function comment
was introduced in 0013288.
This makes stop_listener() function comment easier to read.
(cherry picked from commit 187396e34ed1ab28e73ebcd678fbe7acc32eaad4)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Depending on the timing, the conneciton on lisrv listener may be fully
accepted before any reject. Thus, instead of getting a socket error, an
invalid L7 response is reported. There is no reason to be strick on the
error type. Any failure is good here, because we just want to test the
email-alert feature.
This patch should fix issue #1857. It may be backported as far as 2.2.
(cherry picked from commit 28bc152aa4a42ba91818aaf2af33ccb76f75a426)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Since this counter was added, it was incremented at the wrong place for
client streams. It was incremented when the stream-connector (formely the
conn-stream) was created while it should be done when the H1 stream is
created. Thus, on parsing error, on H1>H2 upgrades or TCP>H1 upgrades, the
counter is not incremented. However, it is always decremented when the H1
stream is destroyed.
On bakcned side, there is no issue.
This patch must be backported to 2.6.
(cherry picked from commit af5336fd238ad2dcac8c09c45720152e36be7bb9)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
As reported by Ilya and Coverity in issue #1858, since recent commit
eea152ee6 ("BUG/MINOR: signals/poller: ensure wakeup from signals")
which removed the test for the global signal flag from the pollers'
loop, the remaining "wake" flag doesn't need to be tested since it
already participates to zeroing the wait_time and will be caught
on the previous line.
Let's just remove that test now.
(cherry picked from commit af985e0151c7d12d9dac4fc364b5c50d3db1e1db)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
This patch adresses the issue #1626.
Adding support for PR_FL_PAUSED flag in the function stats_fill_fe_stats().
The command 'show stat' now properly reports a disabled frontend
using "PAUSED" state label.
This patch depends on the following commits:
- 7d00077fd5 "BUG/MEDIUM: proxy: ensure pause_proxy()
and resume_proxy() own PROXY_LOCK".
- 001328873c "MINOR: listener: small API change"
- d46f437de6 "MINOR: proxy/listener: support for additional PAUSED state"
It should be backported to 2.6, 2.5 and 2.4
(cherry picked from commit cddec0aef526f2dc64bad5a83ad788d60c12639c)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
This patch is a prerequisite for #1626.
Adding PAUSED state to the list of available proxy states.
The flag is set when the proxy is paused at runtime (pause_listener()).
It is cleared when the proxy is resumed (resume_listener()).
It should be backported to 2.6, 2.5 and 2.4
(cherry picked from commit d46f437de69d5d4d84a207531a3ba6f8d3d697dc)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
A minor API change was performed in listener(.c/.h) to restore consistency
between stop_listener() and (resume/pause)_listener() functions.
LISTENER_LOCK was never locked prior to calling stop_listener():
lli variable hint is thus not useful anymore.
Added PROXY_LOCK locking in (resume/pause)_listener() functions
with related lpx variable hint (prerequisite for #1626).
It should be backported to 2.6, 2.5 and 2.4
(cherry picked from commit 001328873c352e5e4b1df0dcc8facaf2fc1408aa)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
There was a race involving hlua_proxy_* functions
and some proxy management functions.
pause_proxy() and resume_proxy() can be used directly from lua code,
but that could lead to some race as lua code didn't make sure PROXY_LOCK
was owned before calling the proxy functions.
This patch makes sure it won't happen again elsewhere in the code
by locking PROXY_LOCK directly in resume and pause proxy functions
so that it's not the caller's responsibility anymore.
(based on stop_proxy() behavior that was already safe prior to the patch)
This should be backported to stable series.
Note that the API will likely differ < 2.4
(cherry picked from commit 7d00077fd5bd21e13aa976e6f3221cd44ae05eea)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
This was added in 2.6 by commit c78a9698e ("MINOR: connection: add a new
flag CO_FL_FDLESS on fd-less connections") but forgotten in flags.c.
This must be backported to 2.6.
(cherry picked from commit 20273ceec0a6ec2645ee26c44dcc20c57ed0c92e)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
The proposed decoding options were not updated after the changes in 2.6,
let's fix that by taking the names from the existing declaration. This
should be backported to 2.6.
(cherry picked from commit c7ac17412b3478eed1725d73e8f51b8cc1118d93)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
we use FreeBSD binary packages that we rebuilt for FreeBSD-13.1
Newer FreeBSD version for package zstd:
To ignore this error set IGNORE_OSVERSION=yes
- package: 1301000
- running kernel: 1300139
(cherry picked from commit b0ab121da142b68d2a53311eff5f9b66dc62531f)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Add self-wake in signal_handler() to fix a race condition with a signal
coming in between checking signal_queue_len and entering polling sleep.
The changes in commit 43c891dda ("BUG/MINOR: signals/poller: set the
poller timeout to 0 when there are signals") were insufficient.
Move the signal_queue_len check from the poll implementations to
run_poll_loop() to keep that logic in one place.
The poll loops are terminated either by the parameter wake being set or
wake up due to a write to their poller_wr_pipe by wake_thread() in
signal_handler().
This fixes issue #1841.
Must be backported in every stable version.
(cherry picked from commit eea152ee68e82eae49ae188cd1b1fbbf63dc6913)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
This is the ->finalize application callback which prepares the unidirectional STREAM
frames for h3 settings and wakeup the mux I/O handler to send them. As haproxy is
at the same time always waiting for the client request, this makes haproxy
call sendto() to send only about 20 bytes of stream data. Furthermore in case
of heavy loss, this give less chances to short h3 requests to succeed.
Drawback: as at this time the mux sends its streams by their IDs ascending order
the stream 0 is always embedded before the unidirectional stream 3 for h3 settings.
Nevertheless, as these settings may be lost and received after other h3 request
streams, this is permitted by the RFC.
Perhaps there is a better way to do. This will have to be checked with Amaury.
Must be backported to 2.6.
(cherry picked from commit 3dd79d378c86b3ebf60e029f518add5f1ed54815)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
This should help in debbuging issues to be able to associate this trace to a
QUIC connection.
Must be backported to 2.6.
(cherry picked from commit befcf7031d79298ab68c0d19ba77fa991aa9f024)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
