Merge haproxy (2.2.9-2+deb11u3) import into refs/heads/workingbranch

BUG/MAJOR: http/htx: prevent unbounded loop in http_manage_server_side_cookies

Origin: https://git.haproxy.org/?p=haproxy-2.2.git;a=commit;h=eb1bdcb7cf6e7bd1690f7dcc6d97de3d79b54cdc
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2022-0711

Ensure calls to http_find_header() terminate. If a "Set-Cookie2"
header is found then the while(1) loop in
http_manage_server_side_cookies() will never terminate, resulting in
the watchdog firing and the process terminating via SIGABRT.

The while(1) loop becomes unbounded because an unmatched call to
http_find_header("Set-Cookie") will leave ctx->blk=NULL. Subsequent
calls to check for "Set-Cookie2" will now enumerate from the beginning
of all the blocks and will once again match on subsequent
passes (assuming a match first time around), hence the loop becoming
unbounded.

This issue was introduced with HTX and this fix should be backported
to all versions supporting HTX.

Many thanks to Grant Spence (gspence@redhat.com) for working through
this issue with me.

(cherry picked from commit bfb15ab34ead85f64cd6da0e9fb418c9cd14cee8)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit d8ce72f63e115fa0952e6a58e81c3d15dfc0a509)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 86032c309b1f42177826deaa39f7c26903a074ca)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 3cd203d61609fd427234fdb4f793193980860348)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Gbp-Pq: Name 0001-BUG-MAJOR-http-htx-prevent-unbounded-loop-in-http_ma.patch

BUG/MAJOR: htx: fix missing header name length check in htx_add_header/trailer

Shachar Menashe for JFrog Security reported that htx_add_header() and
htx_add_trailer() were missing a length check on the header name. While
this does not allow to overwrite any memory area, it results in bits of
the header name length to slip into the header value length and may
result in forging certain header names on the input. The sad thing here
is that a FIXME comment was present suggesting to add the required length
checks :-(

The injected headers are visible to the HTTP internals and to the config
rules, so haproxy will generally stay synchronized with the server. But
there is one exception which is the content-length header field, because
it is already deduplicated on the input, but before being indexed. As
such, injecting a content-length header after the deduplication stage
may be abused to present a different, shorter one on the other side and
help build a request smuggling attack, or even maybe a response splitting
attack.

As a mitigation measure, it is sufficient to verify that no more than
one such header is present in any message, which is normally the case
thanks to the duplicate checks:

   http-request  deny if { req.hdr_cnt(content-length) gt 1 }
   http-response deny if { res.hdr_cnt(content-length) gt 1 }

This must be backported to all HTX-enabled versions, hence as far as 2.0.
In 2.3 and earlier, the functions are in src/htx.c instead.

Many thanks to Shachar for his work and his responsible report!

[wt: code is in src/htx.c in 2.3 and older]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name 0001-2.0-2.3-BUG-MAJOR-htx-fix-missing-header-name-length-check-i.patch

[PATCH] BUG/MEDIUM: h2: match absolute-path not path-absolute for :path

RFC7540 states that :path follows RFC3986's path-absolute. However
that was a bug introduced in the spec between draft 04 and draft 05
of the spec, which implicitly causes paths starting with "//" to be
forbidden. HTTP/1 (and now HTTP core semantics) made it explicit
that the request-target in origin-form follows a purposely defined
absolute-path defined as 1*(/ segment) to explicitly allow "//".

http2bis now fixes this by relying on absolute-path so that "//"
becomes valid and matches other versions. Full discussion here:

  https://lists.w3.org/Archives/Public/ietf-http-wg/2021JulSep/0245.html

This issue appeared in haproxy with commit 4b8852c70 ("BUG/MAJOR: h2:
verify that :path starts with a '/' before concatenating it") when
making the checks on :path fully comply with the spec, and was backported
as far as 2.0, so this fix must be backported there as well to allow
"//" in H2 again.

(cherry picked from commit 46b7dff8f08cb6c5c3004d8874d6c5bc689a4c51)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 512cee88df5c40f1d3901a82cf6643fe9f74229e)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 65b9cf31a1975eb32e6696059c2bf9f0cfca2dff)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name 0001-BUG-MEDIUM-h2-match-absolute-path-not-path-absolute-.patch

BUG/MEDIUM: h2: give :authority precedence over Host

The wording regarding Host vs :authority in RFC7540 is ambiguous as it
says that an intermediary must produce a host header from :authority if
Host is missing, but doesn't say anything regarding the possibility that
Host and :authority differ, which leaves Host with higher precedence
there. In addition it mentions that clients should use :authority
*instead* of Host, and that H1->H2 should use :authority only if the
original request was in authority form. This leaves some gray area in
the middle of the chain for fully valid H2 requests arboring a Host
header that are forwarded to the other side where it's possible to
drop the Host header and use the authority only after forwarding to a
second H2 layer, thus possibly seeing two different values of Host at
a different stage. There's no such issue when forwarding from H2 to H1
as the authority is dropped only only the Host is kept.

Note that the following request is sufficient to re-normalize such a
request:

   http-request set-header host %[req.hdr(host)]

The new spec in progress (draft-ietf-httpbis-http2bis-03.html) addresses
this trouble by being a bit is stricter on these rules. It clarifies that
:authority must always be used instead of Host and that Host ought to be
ignored. This is much saner as it avoids to convey two distinct values
along the chain. This becomes the protocol-level equivalent of:

   http-request set-uri %[url]

So this patch does exactly this, which we were initially a bit reluctant
to do initially by lack of visibiility about other implementation's
expectations. In addition it slightly simplifies the Host header field
creation by always placing it first in the list of headers instead of
last; this could speed up the look up a little bit.

This needs to be backported to 2.0. The legacy code there is a bit
different but not too much, the code can be simplified to simply
omit host during the copy and continue.

Thanks to Tim Düsterhus for reporting that one.

(cherry picked from commit 872e672e17d3fd22dd9d11d94fd98bb6fdd9779c)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit ab811714690aae3388626d38682b31914729244d)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 00bd4df20c74d22bb057bd11acfc7befe201a7b3)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name 2.2-0005-BUG-MEDIUM-h2-give-authority-precedence-over-Host.patch

BUG/MAJOR: h2: enforce checks on the method syntax before translating to HTX

The situation with message components in H2 is always troubling. They're
produced by the HPACK layer which contains a dictionary of well-known
hardcoded values, yet wants to remain binary transparent and protocol-
agnostic with HTTP just being one user, yet at the H2 layer we're
supposed to enforce some checks on some selected pseudo-headers that
come from internal constants... The :method pseudo-header is no exception
and is not tested when coming from the HPACK layer. This makes it possible
to pass random chars into methods, that can be serialized on another H2
connection (where they would not harm), or worse, on an H1 connection
where they can be used to transform the forwareded request. This is
similar to the request line injection described here:

   https://portswigger.net/research/http2

A workaround here is to reject malformed methods by placing this rule
in the frontend or backend, at least before leaving haproxy in H1:

   http-request reject if { method -m reg [^A-Z0-9] }

Alternately H2 may be globally disabled by commenting out the "alpn"
directive on "bind" lines, and by rejecting H2 streams creation by
adding the following statement to the global section:

   tune.h2.max-concurrent-streams 0

This patch adds a check for each character of the method to be part of
the ones permitted in a token, as mentioned in RFC7231#4.1. This should
be backported to versions 2.0 and above, maybe even 1.8. For older
versions not having HTX_FL_PARSING_ERROR, a "goto fail" works as well
as it results in a protocol error at the stream level. Non-HTX versions
were initially thought to be safe but must be carefully rechecked since
they transcode the request into H1 before processing it.

Thanks to Tim Düsterhus for reporting that one.

(cherry picked from commit b4be735a0a7c4a00bf3d774334763536774d7eea)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 6b827f661374704e91322a82197bbfbfbf910f70)
[wt: adapted since no meth_sl in 2.3]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit fbeb053d1a83faedbf3edbe04bde39bc7304cddd)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name 2.2-0004-BUG-MAJOR-h2-enforce-checks-on-the-method-syntax-bef.patch

BUG/MAJOR: h2: verify that :path starts with a '/' before concatenating it

Tim Düsterhus found that while the H2 path is checked for non-emptiness,
invalid chars and '*', a test is missing to verify that except for '*',
it always starts with exactly one '/'. During the reconstruction of the
full URI when passing to HTX, this allows to affect the apparent authority
by appending a port number or a suffix name.

This only affects H2-to-H2 communications, as H2-to-H1 do not use the
authority. Like for previous fix, the following rule installed in the
frontend or backend is sufficient to renormalize the internal URI:

    http-request set-header host %[req.hdr(host)]

This needs to be backported to 2.2, since earlier versions do not rebuild
a full URI using the authority and will fail on the malformed path at the
HTTP layer.

(cherry picked from commit d3b22b75025246e81ff8d0c78837d4b89d7cf8f8)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 2360306269ff65420cba7c847687a774b1025ab5)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit c99c5cd3588a28978cd065abc74508fe81a93a40)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name 2.2-0003-BUG-MAJOR-h2-verify-that-path-starts-with-a-before-c.patch

BUG/MAJOR: h2: verify early that non-http/https schemes match the valid syntax

While we do explicitly check for strict character sets in the scheme,
this is only done when extracting URL components from an assembled one,
and we have special handling for "http" and "https" schemes directly in
the H2-to-HTX conversion. Sadly, this lets all other ones pass through
if they start exactly with "http://" or "https://", allowing the
reconstructed URI to start with a different looking authority if it was
part of the scheme.

It's interesting to note that in this case the valid authority is in
the Host hedaer and that the request will only be wrong if emitted over
H2 on the backend side, since H1 will not emit an absolute URI by
default and will drop the scheme. So in essence, this is a variant of
the scheme-based attack described below in that it only affects H2-H2
and not H2-H1 forwarding:

   https://portswigger.net/research/http2

As such, a simple workaround consists in just adding the following
rule in the frontend or backend, which will have for effect to
renormalize the authority in the request line according to the
concatenated version:

   http-request set-uri %[url]

This patch simply adds the missing syntax checks for non-http/https
schemes before the concatenation in the H2 code. An improvement may
consist in the future in splitting these ones apart in the start
line so that only the "url" sample fetch function requires to access
them together and that all other places continue to access them
separately. This will then allow the core code to perform such checks
itself.

The patch needs to be backported as far as 2.2. Before 2.2 the full
URI was not being reconstructed so the scheme and authority part were
always dropped from H2 requests to leave only origin requests. Note
for backporters: this depends on this previous patch:

  MINOR: http: add a new function http_validate_scheme() to validate a scheme

Many thanks to Tim Düsterhus for figuring that one and providing a
reproducer.

(cherry picked from commit d2b179db54846aee11356f033dfc490978147593)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 2ac4f553cc1ea7a8a4ff28db18fa01f04b9d84ce)
[wt: no rfc8441 in 2.3]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit e618d9bf5f6b48bb45aceb8e7a886c43d62b3ed5)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name 2.2-0002-BUG-MAJOR-h2-verify-early-that-non-http-https-scheme.patch

MINOR: http: add a new function http_validate_scheme() to validate a scheme

While http_parse_scheme() extracts a scheme from a URI by extracting
exactly the valid characters and stopping on delimiters, this new
function performs the same on a fixed-size string.

(cherry picked from commit adfc08e717db600c3ac44ca8f3178d861699b67c)
[wt: context adj]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 073e9c9c10897a05117f29cb9d3ebdbc13ff03b5)
[wt: context adj]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 0fb53c3c025fb158c51c515532f3f52bb2abcdea)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name 2.2-0001-MINOR-http-add-a-new-function-http_validate_scheme-t.patch

[PATCH] BUG/MINOR: tcpcheck: Update .health threshold of agent inside an agent-check

If an agent-check is configured for a server, When the response is parsed,
the .health threshold of the agent must be updated on up/down/stopped/fail
command and not the threshold of the health-check. Otherwise, the
agent-check will compete with the health-check and may mark a DOWN server as
UP.

This patch should fix the issue #1176. It must be backported as far as 2.2.

(cherry picked from commit 24ec9434271345857b42cc5bd9c6b497ab01a7e4)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 789bbdc88d7ffe8f520532efb18148ea52ede4ca)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Gbp-Pq: Name 0001-BUG-MINOR-tcpcheck-Update-.health-threshold-of-agent.patch

Add documentation field to the systemd unit

Forwarded: no
Last-Update: 2014-01-03

Gbp-Pq: Name haproxy.service-add-documentation.patch

Start after rsyslog.service

As HAProxy is running chrooted by default, we rely on an additional syslog
socket created by rsyslog inside the chroot for logging. As this socket cannot
trigger syslog activation, we explicitly order HAProxy after rsyslog.service.
Note that we are not using syslog.service here, since the additional socket is
rsyslog-specific.
Forwarded: no
Last-Update: 2017-12-01

Gbp-Pq: Name haproxy.service-start-after-syslog.patch

Use dpkg-buildflags to build halog

Forwarded: no
Last-Update: 2013-07-02

Gbp-Pq: Name 0002-Use-dpkg-buildflags-to-build-halog.patch

haproxy (2.2.9-2+deb11u3) bullseye-security; urgency=high

  * Non-maintainer upload by the Security Team.
  * BUG/MAJOR: http/htx: prevent unbounded loop in
    http_manage_server_side_cookies (CVE-2022-0711)

[dgit import unpatched haproxy 2.2.9-2+deb11u3]

Import haproxy_2.2.9-2+deb11u3.debian.tar.xz

[dgit import tarball haproxy 2.2.9-2+deb11u3 haproxy_2.2.9-2+deb11u3.debian.tar.xz]

Merge haproxy (2.2.9-2+deb11u2) import into refs/heads/workingbranch

BUG/MAJOR: htx: fix missing header name length check in htx_add_header/trailer

Shachar Menashe for JFrog Security reported that htx_add_header() and
htx_add_trailer() were missing a length check on the header name. While
this does not allow to overwrite any memory area, it results in bits of
the header name length to slip into the header value length and may
result in forging certain header names on the input. The sad thing here
is that a FIXME comment was present suggesting to add the required length
checks :-(

The injected headers are visible to the HTTP internals and to the config
rules, so haproxy will generally stay synchronized with the server. But
there is one exception which is the content-length header field, because
it is already deduplicated on the input, but before being indexed. As
such, injecting a content-length header after the deduplication stage
may be abused to present a different, shorter one on the other side and
help build a request smuggling attack, or even maybe a response splitting
attack.

As a mitigation measure, it is sufficient to verify that no more than
one such header is present in any message, which is normally the case
thanks to the duplicate checks:

   http-request  deny if { req.hdr_cnt(content-length) gt 1 }
   http-response deny if { res.hdr_cnt(content-length) gt 1 }

This must be backported to all HTX-enabled versions, hence as far as 2.0.
In 2.3 and earlier, the functions are in src/htx.c instead.

Many thanks to Shachar for his work and his responsible report!

[wt: code is in src/htx.c in 2.3 and older]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name 0001-2.0-2.3-BUG-MAJOR-htx-fix-missing-header-name-length-check-i.patch

[PATCH] BUG/MEDIUM: h2: match absolute-path not path-absolute for :path

RFC7540 states that :path follows RFC3986's path-absolute. However
that was a bug introduced in the spec between draft 04 and draft 05
of the spec, which implicitly causes paths starting with "//" to be
forbidden. HTTP/1 (and now HTTP core semantics) made it explicit
that the request-target in origin-form follows a purposely defined
absolute-path defined as 1*(/ segment) to explicitly allow "//".

http2bis now fixes this by relying on absolute-path so that "//"
becomes valid and matches other versions. Full discussion here:

  https://lists.w3.org/Archives/Public/ietf-http-wg/2021JulSep/0245.html

This issue appeared in haproxy with commit 4b8852c70 ("BUG/MAJOR: h2:
verify that :path starts with a '/' before concatenating it") when
making the checks on :path fully comply with the spec, and was backported
as far as 2.0, so this fix must be backported there as well to allow
"//" in H2 again.

(cherry picked from commit 46b7dff8f08cb6c5c3004d8874d6c5bc689a4c51)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 512cee88df5c40f1d3901a82cf6643fe9f74229e)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 65b9cf31a1975eb32e6696059c2bf9f0cfca2dff)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name 0001-BUG-MEDIUM-h2-match-absolute-path-not-path-absolute-.patch

BUG/MEDIUM: h2: give :authority precedence over Host

The wording regarding Host vs :authority in RFC7540 is ambiguous as it
says that an intermediary must produce a host header from :authority if
Host is missing, but doesn't say anything regarding the possibility that
Host and :authority differ, which leaves Host with higher precedence
there. In addition it mentions that clients should use :authority
*instead* of Host, and that H1->H2 should use :authority only if the
original request was in authority form. This leaves some gray area in
the middle of the chain for fully valid H2 requests arboring a Host
header that are forwarded to the other side where it's possible to
drop the Host header and use the authority only after forwarding to a
second H2 layer, thus possibly seeing two different values of Host at
a different stage. There's no such issue when forwarding from H2 to H1
as the authority is dropped only only the Host is kept.

Note that the following request is sufficient to re-normalize such a
request:

   http-request set-header host %[req.hdr(host)]

The new spec in progress (draft-ietf-httpbis-http2bis-03.html) addresses
this trouble by being a bit is stricter on these rules. It clarifies that
:authority must always be used instead of Host and that Host ought to be
ignored. This is much saner as it avoids to convey two distinct values
along the chain. This becomes the protocol-level equivalent of:

   http-request set-uri %[url]

So this patch does exactly this, which we were initially a bit reluctant
to do initially by lack of visibiility about other implementation's
expectations. In addition it slightly simplifies the Host header field
creation by always placing it first in the list of headers instead of
last; this could speed up the look up a little bit.

This needs to be backported to 2.0. The legacy code there is a bit
different but not too much, the code can be simplified to simply
omit host during the copy and continue.

Thanks to Tim Düsterhus for reporting that one.

(cherry picked from commit 872e672e17d3fd22dd9d11d94fd98bb6fdd9779c)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit ab811714690aae3388626d38682b31914729244d)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 00bd4df20c74d22bb057bd11acfc7befe201a7b3)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name 2.2-0005-BUG-MEDIUM-h2-give-authority-precedence-over-Host.patch

BUG/MAJOR: h2: enforce checks on the method syntax before translating to HTX

The situation with message components in H2 is always troubling. They're
produced by the HPACK layer which contains a dictionary of well-known
hardcoded values, yet wants to remain binary transparent and protocol-
agnostic with HTTP just being one user, yet at the H2 layer we're
supposed to enforce some checks on some selected pseudo-headers that
come from internal constants... The :method pseudo-header is no exception
and is not tested when coming from the HPACK layer. This makes it possible
to pass random chars into methods, that can be serialized on another H2
connection (where they would not harm), or worse, on an H1 connection
where they can be used to transform the forwareded request. This is
similar to the request line injection described here:

   https://portswigger.net/research/http2

A workaround here is to reject malformed methods by placing this rule
in the frontend or backend, at least before leaving haproxy in H1:

   http-request reject if { method -m reg [^A-Z0-9] }

Alternately H2 may be globally disabled by commenting out the "alpn"
directive on "bind" lines, and by rejecting H2 streams creation by
adding the following statement to the global section:

   tune.h2.max-concurrent-streams 0

This patch adds a check for each character of the method to be part of
the ones permitted in a token, as mentioned in RFC7231#4.1. This should
be backported to versions 2.0 and above, maybe even 1.8. For older
versions not having HTX_FL_PARSING_ERROR, a "goto fail" works as well
as it results in a protocol error at the stream level. Non-HTX versions
were initially thought to be safe but must be carefully rechecked since
they transcode the request into H1 before processing it.

Thanks to Tim Düsterhus for reporting that one.

(cherry picked from commit b4be735a0a7c4a00bf3d774334763536774d7eea)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 6b827f661374704e91322a82197bbfbfbf910f70)
[wt: adapted since no meth_sl in 2.3]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit fbeb053d1a83faedbf3edbe04bde39bc7304cddd)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name 2.2-0004-BUG-MAJOR-h2-enforce-checks-on-the-method-syntax-bef.patch

BUG/MAJOR: h2: verify that :path starts with a '/' before concatenating it

Tim Düsterhus found that while the H2 path is checked for non-emptiness,
invalid chars and '*', a test is missing to verify that except for '*',
it always starts with exactly one '/'. During the reconstruction of the
full URI when passing to HTX, this allows to affect the apparent authority
by appending a port number or a suffix name.

This only affects H2-to-H2 communications, as H2-to-H1 do not use the
authority. Like for previous fix, the following rule installed in the
frontend or backend is sufficient to renormalize the internal URI:

    http-request set-header host %[req.hdr(host)]

This needs to be backported to 2.2, since earlier versions do not rebuild
a full URI using the authority and will fail on the malformed path at the
HTTP layer.

(cherry picked from commit d3b22b75025246e81ff8d0c78837d4b89d7cf8f8)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 2360306269ff65420cba7c847687a774b1025ab5)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit c99c5cd3588a28978cd065abc74508fe81a93a40)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name 2.2-0003-BUG-MAJOR-h2-verify-that-path-starts-with-a-before-c.patch

BUG/MAJOR: h2: verify early that non-http/https schemes match the valid syntax

While we do explicitly check for strict character sets in the scheme,
this is only done when extracting URL components from an assembled one,
and we have special handling for "http" and "https" schemes directly in
the H2-to-HTX conversion. Sadly, this lets all other ones pass through
if they start exactly with "http://" or "https://", allowing the
reconstructed URI to start with a different looking authority if it was
part of the scheme.

It's interesting to note that in this case the valid authority is in
the Host hedaer and that the request will only be wrong if emitted over
H2 on the backend side, since H1 will not emit an absolute URI by
default and will drop the scheme. So in essence, this is a variant of
the scheme-based attack described below in that it only affects H2-H2
and not H2-H1 forwarding:

   https://portswigger.net/research/http2

As such, a simple workaround consists in just adding the following
rule in the frontend or backend, which will have for effect to
renormalize the authority in the request line according to the
concatenated version:

   http-request set-uri %[url]

This patch simply adds the missing syntax checks for non-http/https
schemes before the concatenation in the H2 code. An improvement may
consist in the future in splitting these ones apart in the start
line so that only the "url" sample fetch function requires to access
them together and that all other places continue to access them
separately. This will then allow the core code to perform such checks
itself.

The patch needs to be backported as far as 2.2. Before 2.2 the full
URI was not being reconstructed so the scheme and authority part were
always dropped from H2 requests to leave only origin requests. Note
for backporters: this depends on this previous patch:

  MINOR: http: add a new function http_validate_scheme() to validate a scheme

Many thanks to Tim Düsterhus for figuring that one and providing a
reproducer.

(cherry picked from commit d2b179db54846aee11356f033dfc490978147593)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 2ac4f553cc1ea7a8a4ff28db18fa01f04b9d84ce)
[wt: no rfc8441 in 2.3]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit e618d9bf5f6b48bb45aceb8e7a886c43d62b3ed5)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name 2.2-0002-BUG-MAJOR-h2-verify-early-that-non-http-https-scheme.patch

MINOR: http: add a new function http_validate_scheme() to validate a scheme

While http_parse_scheme() extracts a scheme from a URI by extracting
exactly the valid characters and stopping on delimiters, this new
function performs the same on a fixed-size string.

(cherry picked from commit adfc08e717db600c3ac44ca8f3178d861699b67c)
[wt: context adj]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 073e9c9c10897a05117f29cb9d3ebdbc13ff03b5)
[wt: context adj]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 0fb53c3c025fb158c51c515532f3f52bb2abcdea)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name 2.2-0001-MINOR-http-add-a-new-function-http_validate_scheme-t.patch

[PATCH] BUG/MINOR: tcpcheck: Update .health threshold of agent inside an agent-check

If an agent-check is configured for a server, When the response is parsed,
the .health threshold of the agent must be updated on up/down/stopped/fail
command and not the threshold of the health-check. Otherwise, the
agent-check will compete with the health-check and may mark a DOWN server as
UP.

This patch should fix the issue #1176. It must be backported as far as 2.2.

(cherry picked from commit 24ec9434271345857b42cc5bd9c6b497ab01a7e4)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 789bbdc88d7ffe8f520532efb18148ea52ede4ca)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Gbp-Pq: Name 0001-BUG-MINOR-tcpcheck-Update-.health-threshold-of-agent.patch

Add documentation field to the systemd unit

Forwarded: no
Last-Update: 2014-01-03

Gbp-Pq: Name haproxy.service-add-documentation.patch

Start after rsyslog.service

As HAProxy is running chrooted by default, we rely on an additional syslog
socket created by rsyslog inside the chroot for logging. As this socket cannot
trigger syslog activation, we explicitly order HAProxy after rsyslog.service.
Note that we are not using syslog.service here, since the additional socket is
rsyslog-specific.
Forwarded: no
Last-Update: 2017-12-01

Gbp-Pq: Name haproxy.service-start-after-syslog.patch

Use dpkg-buildflags to build halog

Forwarded: no
Last-Update: 2013-07-02

Gbp-Pq: Name 0002-Use-dpkg-buildflags-to-build-halog.patch

haproxy (2.2.9-2+deb11u2) bullseye-security; urgency=high

  * d/patches: fix missing header name length check in HTX (CVE-2021-40346).
  * d/patches: h2: match absolute-path not path-absolute for :path.
Closes: #993303.
[dgit import unpatched haproxy 2.2.9-2+deb11u2]

Import haproxy_2.2.9-2+deb11u2.debian.tar.xz

[dgit import tarball haproxy 2.2.9-2+deb11u2 haproxy_2.2.9-2+deb11u2.debian.tar.xz]

Merge haproxy (2.2.9-2+deb11u1) import into refs/heads/workingbranch

BUG/MEDIUM: h2: give :authority precedence over Host

The wording regarding Host vs :authority in RFC7540 is ambiguous as it
says that an intermediary must produce a host header from :authority if
Host is missing, but doesn't say anything regarding the possibility that
Host and :authority differ, which leaves Host with higher precedence
there. In addition it mentions that clients should use :authority
*instead* of Host, and that H1->H2 should use :authority only if the
original request was in authority form. This leaves some gray area in
the middle of the chain for fully valid H2 requests arboring a Host
header that are forwarded to the other side where it's possible to
drop the Host header and use the authority only after forwarding to a
second H2 layer, thus possibly seeing two different values of Host at
a different stage. There's no such issue when forwarding from H2 to H1
as the authority is dropped only only the Host is kept.

Note that the following request is sufficient to re-normalize such a
request:

   http-request set-header host %[req.hdr(host)]

The new spec in progress (draft-ietf-httpbis-http2bis-03.html) addresses
this trouble by being a bit is stricter on these rules. It clarifies that
:authority must always be used instead of Host and that Host ought to be
ignored. This is much saner as it avoids to convey two distinct values
along the chain. This becomes the protocol-level equivalent of:

   http-request set-uri %[url]

So this patch does exactly this, which we were initially a bit reluctant
to do initially by lack of visibiility about other implementation's
expectations. In addition it slightly simplifies the Host header field
creation by always placing it first in the list of headers instead of
last; this could speed up the look up a little bit.

This needs to be backported to 2.0. The legacy code there is a bit
different but not too much, the code can be simplified to simply
omit host during the copy and continue.

Thanks to Tim Düsterhus for reporting that one.

(cherry picked from commit 872e672e17d3fd22dd9d11d94fd98bb6fdd9779c)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit ab811714690aae3388626d38682b31914729244d)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 00bd4df20c74d22bb057bd11acfc7befe201a7b3)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name 2.2-0005-BUG-MEDIUM-h2-give-authority-precedence-over-Host.patch

BUG/MAJOR: h2: enforce checks on the method syntax before translating to HTX

The situation with message components in H2 is always troubling. They're
produced by the HPACK layer which contains a dictionary of well-known
hardcoded values, yet wants to remain binary transparent and protocol-
agnostic with HTTP just being one user, yet at the H2 layer we're
supposed to enforce some checks on some selected pseudo-headers that
come from internal constants... The :method pseudo-header is no exception
and is not tested when coming from the HPACK layer. This makes it possible
to pass random chars into methods, that can be serialized on another H2
connection (where they would not harm), or worse, on an H1 connection
where they can be used to transform the forwareded request. This is
similar to the request line injection described here:

   https://portswigger.net/research/http2

A workaround here is to reject malformed methods by placing this rule
in the frontend or backend, at least before leaving haproxy in H1:

   http-request reject if { method -m reg [^A-Z0-9] }

Alternately H2 may be globally disabled by commenting out the "alpn"
directive on "bind" lines, and by rejecting H2 streams creation by
adding the following statement to the global section:

   tune.h2.max-concurrent-streams 0

This patch adds a check for each character of the method to be part of
the ones permitted in a token, as mentioned in RFC7231#4.1. This should
be backported to versions 2.0 and above, maybe even 1.8. For older
versions not having HTX_FL_PARSING_ERROR, a "goto fail" works as well
as it results in a protocol error at the stream level. Non-HTX versions
were initially thought to be safe but must be carefully rechecked since
they transcode the request into H1 before processing it.

Thanks to Tim Düsterhus for reporting that one.

(cherry picked from commit b4be735a0a7c4a00bf3d774334763536774d7eea)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 6b827f661374704e91322a82197bbfbfbf910f70)
[wt: adapted since no meth_sl in 2.3]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit fbeb053d1a83faedbf3edbe04bde39bc7304cddd)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name 2.2-0004-BUG-MAJOR-h2-enforce-checks-on-the-method-syntax-bef.patch

BUG/MAJOR: h2: verify that :path starts with a '/' before concatenating it

Tim Düsterhus found that while the H2 path is checked for non-emptiness,
invalid chars and '*', a test is missing to verify that except for '*',
it always starts with exactly one '/'. During the reconstruction of the
full URI when passing to HTX, this allows to affect the apparent authority
by appending a port number or a suffix name.

This only affects H2-to-H2 communications, as H2-to-H1 do not use the
authority. Like for previous fix, the following rule installed in the
frontend or backend is sufficient to renormalize the internal URI:

    http-request set-header host %[req.hdr(host)]

This needs to be backported to 2.2, since earlier versions do not rebuild
a full URI using the authority and will fail on the malformed path at the
HTTP layer.

(cherry picked from commit d3b22b75025246e81ff8d0c78837d4b89d7cf8f8)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 2360306269ff65420cba7c847687a774b1025ab5)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit c99c5cd3588a28978cd065abc74508fe81a93a40)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name 2.2-0003-BUG-MAJOR-h2-verify-that-path-starts-with-a-before-c.patch

BUG/MAJOR: h2: verify early that non-http/https schemes match the valid syntax

While we do explicitly check for strict character sets in the scheme,
this is only done when extracting URL components from an assembled one,
and we have special handling for "http" and "https" schemes directly in
the H2-to-HTX conversion. Sadly, this lets all other ones pass through
if they start exactly with "http://" or "https://", allowing the
reconstructed URI to start with a different looking authority if it was
part of the scheme.

It's interesting to note that in this case the valid authority is in
the Host hedaer and that the request will only be wrong if emitted over
H2 on the backend side, since H1 will not emit an absolute URI by
default and will drop the scheme. So in essence, this is a variant of
the scheme-based attack described below in that it only affects H2-H2
and not H2-H1 forwarding:

   https://portswigger.net/research/http2

As such, a simple workaround consists in just adding the following
rule in the frontend or backend, which will have for effect to
renormalize the authority in the request line according to the
concatenated version:

   http-request set-uri %[url]

This patch simply adds the missing syntax checks for non-http/https
schemes before the concatenation in the H2 code. An improvement may
consist in the future in splitting these ones apart in the start
line so that only the "url" sample fetch function requires to access
them together and that all other places continue to access them
separately. This will then allow the core code to perform such checks
itself.

The patch needs to be backported as far as 2.2. Before 2.2 the full
URI was not being reconstructed so the scheme and authority part were
always dropped from H2 requests to leave only origin requests. Note
for backporters: this depends on this previous patch:

  MINOR: http: add a new function http_validate_scheme() to validate a scheme

Many thanks to Tim Düsterhus for figuring that one and providing a
reproducer.

(cherry picked from commit d2b179db54846aee11356f033dfc490978147593)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 2ac4f553cc1ea7a8a4ff28db18fa01f04b9d84ce)
[wt: no rfc8441 in 2.3]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit e618d9bf5f6b48bb45aceb8e7a886c43d62b3ed5)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name 2.2-0002-BUG-MAJOR-h2-verify-early-that-non-http-https-scheme.patch

MINOR: http: add a new function http_validate_scheme() to validate a scheme

While http_parse_scheme() extracts a scheme from a URI by extracting
exactly the valid characters and stopping on delimiters, this new
function performs the same on a fixed-size string.

(cherry picked from commit adfc08e717db600c3ac44ca8f3178d861699b67c)
[wt: context adj]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 073e9c9c10897a05117f29cb9d3ebdbc13ff03b5)
[wt: context adj]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 0fb53c3c025fb158c51c515532f3f52bb2abcdea)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name 2.2-0001-MINOR-http-add-a-new-function-http_validate_scheme-t.patch

[PATCH] BUG/MINOR: tcpcheck: Update .health threshold of agent inside an agent-check

If an agent-check is configured for a server, When the response is parsed,
the .health threshold of the agent must be updated on up/down/stopped/fail
command and not the threshold of the health-check. Otherwise, the
agent-check will compete with the health-check and may mark a DOWN server as
UP.

This patch should fix the issue #1176. It must be backported as far as 2.2.

(cherry picked from commit 24ec9434271345857b42cc5bd9c6b497ab01a7e4)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 789bbdc88d7ffe8f520532efb18148ea52ede4ca)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Gbp-Pq: Name 0001-BUG-MINOR-tcpcheck-Update-.health-threshold-of-agent.patch

Add documentation field to the systemd unit

Forwarded: no
Last-Update: 2014-01-03

Gbp-Pq: Name haproxy.service-add-documentation.patch

Start after rsyslog.service

As HAProxy is running chrooted by default, we rely on an additional syslog
socket created by rsyslog inside the chroot for logging. As this socket cannot
trigger syslog activation, we explicitly order HAProxy after rsyslog.service.
Note that we are not using syslog.service here, since the additional socket is
rsyslog-specific.
Forwarded: no
Last-Update: 2017-12-01

Gbp-Pq: Name haproxy.service-start-after-syslog.patch

Use dpkg-buildflags to build halog

Forwarded: no
Last-Update: 2013-07-02

Gbp-Pq: Name 0002-Use-dpkg-buildflags-to-build-halog.patch

haproxy (2.2.9-2+deb11u1) bullseye-security; urgency=high

  * Fix HTTP request smuggling via HTTP/2 desync attacks.

[dgit import unpatched haproxy 2.2.9-2+deb11u1]

Import haproxy_2.2.9-2+deb11u1.debian.tar.xz

[dgit import tarball haproxy 2.2.9-2+deb11u1 haproxy_2.2.9-2+deb11u1.debian.tar.xz]

Merge haproxy (2.2.9-2) import into refs/heads/workingbranch

[PATCH] BUG/MINOR: tcpcheck: Update .health threshold of agent inside an agent-check

If an agent-check is configured for a server, When the response is parsed,
the .health threshold of the agent must be updated on up/down/stopped/fail
command and not the threshold of the health-check. Otherwise, the
agent-check will compete with the health-check and may mark a DOWN server as
UP.

This patch should fix the issue #1176. It must be backported as far as 2.2.

(cherry picked from commit 24ec9434271345857b42cc5bd9c6b497ab01a7e4)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 789bbdc88d7ffe8f520532efb18148ea52ede4ca)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Gbp-Pq: Name 0001-BUG-MINOR-tcpcheck-Update-.health-threshold-of-agent.patch

Add documentation field to the systemd unit

Forwarded: no
Last-Update: 2014-01-03

Gbp-Pq: Name haproxy.service-add-documentation.patch

Start after rsyslog.service

As HAProxy is running chrooted by default, we rely on an additional syslog
socket created by rsyslog inside the chroot for logging. As this socket cannot
trigger syslog activation, we explicitly order HAProxy after rsyslog.service.
Note that we are not using syslog.service here, since the additional socket is
rsyslog-specific.
Forwarded: no
Last-Update: 2017-12-01

Gbp-Pq: Name haproxy.service-start-after-syslog.patch

Use dpkg-buildflags to build halog

Forwarded: no
Last-Update: 2013-07-02

Gbp-Pq: Name 0002-Use-dpkg-buildflags-to-build-halog.patch

haproxy (2.2.9-2) unstable; urgency=medium

  * d/patches: fix agent-check regression putting down servers.
Closes: #988779.
[dgit import unpatched haproxy 2.2.9-2]

Import haproxy_2.2.9-2.debian.tar.xz

[dgit import tarball haproxy 2.2.9-2 haproxy_2.2.9-2.debian.tar.xz]

Import haproxy_2.2.9.orig.tar.gz

[dgit import orig haproxy_2.2.9.orig.tar.gz]

Merge haproxy (2.2.9-1) import into refs/heads/workingbranch

Add documentation field to the systemd unit

Forwarded: no
Last-Update: 2014-01-03

Gbp-Pq: Name haproxy.service-add-documentation.patch

Start after rsyslog.service

As HAProxy is running chrooted by default, we rely on an additional syslog
socket created by rsyslog inside the chroot for logging. As this socket cannot
trigger syslog activation, we explicitly order HAProxy after rsyslog.service.
Note that we are not using syslog.service here, since the additional socket is
rsyslog-specific.
Forwarded: no
Last-Update: 2017-12-01

Gbp-Pq: Name haproxy.service-start-after-syslog.patch

Use dpkg-buildflags to build halog

Forwarded: no
Last-Update: 2013-07-02

Gbp-Pq: Name 0002-Use-dpkg-buildflags-to-build-halog.patch

haproxy (2.2.9-1) unstable; urgency=medium

  * New upstream release.
    - BUG/MAJOR: connection: reset conn->owner when detaching from session
                 list

[dgit import unpatched haproxy 2.2.9-1]

Import haproxy_2.2.9-1.debian.tar.xz

[dgit import tarball haproxy 2.2.9-1 haproxy_2.2.9-1.debian.tar.xz]

Merge haproxy (2.2.8-1) import into refs/heads/workingbranch

Add documentation field to the systemd unit

Forwarded: no
Last-Update: 2014-01-03

Gbp-Pq: Name haproxy.service-add-documentation.patch

Start after rsyslog.service

As HAProxy is running chrooted by default, we rely on an additional syslog
socket created by rsyslog inside the chroot for logging. As this socket cannot
trigger syslog activation, we explicitly order HAProxy after rsyslog.service.
Note that we are not using syslog.service here, since the additional socket is
rsyslog-specific.
Forwarded: no
Last-Update: 2017-12-01

Gbp-Pq: Name haproxy.service-start-after-syslog.patch

Use dpkg-buildflags to build halog

Forwarded: no
Last-Update: 2013-07-02

Gbp-Pq: Name 0002-Use-dpkg-buildflags-to-build-halog.patch

haproxy (2.2.8-1) unstable; urgency=medium

  * New upstream release.
    - Revert "BUG/MINOR: dns: SRV records ignores duplicated AR records"

[dgit import unpatched haproxy 2.2.8-1]

Import haproxy_2.2.8.orig.tar.gz

[dgit import orig haproxy_2.2.8.orig.tar.gz]

Import haproxy_2.2.8-1.debian.tar.xz

[dgit import tarball haproxy 2.2.8-1 haproxy_2.2.8-1.debian.tar.xz]

Merge haproxy (2.2.7-1) import into refs/heads/workingbranch

Add documentation field to the systemd unit

Forwarded: no
Last-Update: 2014-01-03

Gbp-Pq: Name haproxy.service-add-documentation.patch

Start after rsyslog.service

As HAProxy is running chrooted by default, we rely on an additional syslog
socket created by rsyslog inside the chroot for logging. As this socket cannot
trigger syslog activation, we explicitly order HAProxy after rsyslog.service.
Note that we are not using syslog.service here, since the additional socket is
rsyslog-specific.
Forwarded: no
Last-Update: 2017-12-01

Gbp-Pq: Name haproxy.service-start-after-syslog.patch

Use dpkg-buildflags to build halog

Forwarded: no
Last-Update: 2013-07-02

Gbp-Pq: Name 0002-Use-dpkg-buildflags-to-build-halog.patch

haproxy (2.2.7-1) unstable; urgency=medium

  * New upstream release.
    - BUG/MAJOR: ring: tcp forward on ring can break the reader counter.
    - BUG/MAJOR: spoa/python: Fixing return None

[dgit import unpatched haproxy 2.2.7-1]

Import haproxy_2.2.7.orig.tar.gz

[dgit import orig haproxy_2.2.7.orig.tar.gz]

Import haproxy_2.2.7-1.debian.tar.xz

[dgit import tarball haproxy 2.2.7-1 haproxy_2.2.7-1.debian.tar.xz]

Merge haproxy (2.2.6-2) import into refs/heads/workingbranch

Add documentation field to the systemd unit

Forwarded: no
Last-Update: 2014-01-03

Gbp-Pq: Name haproxy.service-add-documentation.patch

Start after rsyslog.service

As HAProxy is running chrooted by default, we rely on an additional syslog
socket created by rsyslog inside the chroot for logging. As this socket cannot
trigger syslog activation, we explicitly order HAProxy after rsyslog.service.
Note that we are not using syslog.service here, since the additional socket is
rsyslog-specific.
Forwarded: no
Last-Update: 2017-12-01

Gbp-Pq: Name haproxy.service-start-after-syslog.patch

Use dpkg-buildflags to build halog

Forwarded: no
Last-Update: 2013-07-02

Gbp-Pq: Name 0002-Use-dpkg-buildflags-to-build-halog.patch

haproxy (2.2.6-2) unstable; urgency=medium

  * d/tests: sleep before test to let Apache2 start.
Closes: #976997.
[dgit import unpatched haproxy 2.2.6-2]

Import haproxy_2.2.6-2.debian.tar.xz

[dgit import tarball haproxy 2.2.6-2 haproxy_2.2.6-2.debian.tar.xz]

Merge haproxy (2.2.6-1) import into refs/heads/workingbranch

Import haproxy_2.2.6.orig.tar.gz

[dgit import orig haproxy_2.2.6.orig.tar.gz]

Add documentation field to the systemd unit

Forwarded: no
Last-Update: 2014-01-03

Gbp-Pq: Name haproxy.service-add-documentation.patch

Start after rsyslog.service

As HAProxy is running chrooted by default, we rely on an additional syslog
socket created by rsyslog inside the chroot for logging. As this socket cannot
trigger syslog activation, we explicitly order HAProxy after rsyslog.service.
Note that we are not using syslog.service here, since the additional socket is
rsyslog-specific.
Forwarded: no
Last-Update: 2017-12-01

Gbp-Pq: Name haproxy.service-start-after-syslog.patch

Use dpkg-buildflags to build halog

Forwarded: no
Last-Update: 2013-07-02

Gbp-Pq: Name 0002-Use-dpkg-buildflags-to-build-halog.patch

haproxy (2.2.6-1) unstable; urgency=medium

  * New upstream release.
    - BUG/MAJOR: filters: Always keep all offsets up to date during data
                 filtering
    - BUG/MAJOR: peers: fix partial message decoding
    - BUG/MAJOR: spoe: Be sure to remove all references on a released spoe
                 applet
    - BUG/MAJOR: tcpcheck: Allocate input and output buffers from the buffer
                 pool
  * d/patches: remove patches applied upstream

[dgit import unpatched haproxy 2.2.6-1]

Import haproxy_2.2.6-1.debian.tar.xz

[dgit import tarball haproxy 2.2.6-1 haproxy_2.2.6-1.debian.tar.xz]

Merge haproxy (2.2.5-2) import into refs/heads/workingbranch

[PATCH 2/2] BUG/MINOR: http-htx: Just warn if payload of an errorfile doesn't match the C-L

During startup, when an errorfile is parsed, if its payload does not match the
announced content-length, an error is triggered. This change was introduced in
the 2.3, which is ok. But for a stable release it may be seen as a
regression. Thus, now a warning is emitted, instead of an error. And the
content-length header is updated with the real payload length.

This patch depends on 58f55acf4e ("MINOR: http-htx: Add understandable errors
for the errorfiles parsing"). Both must be backported as far as 2.0. This bug
only exists in the 2.2, 2.1 and 2.0. Thus, there is no upstream commit ID for
this patch.

Gbp-Pq: Name 0002-BUG-MINOR-http-htx-Just-warn-if-payload-of-an-errorf.patch

[PATCH 1/2] MINOR: http-htx: Add understandable errors for the errorfiles parsing

No details are provided when an error occurs during the parsing of an errorfile,
Thus it is a bit hard to diagnose where the problem is. Now, when it happens, an
understandable error message is reported.

This patch is not a bug fix in itself. But it will be required to change an
fatal error into a warning in last stable releases. Thus it must be backported
as far as 2.0.

(cherry picked from commit a66adf41ea28a0fa29437d1675f225b5cc589b59)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 3a10710b777370ef36763b8b6658ae63ef5c4ec4)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Gbp-Pq: Name 0001-MINOR-http-htx-Add-understandable-errors-for-the-err.patch

Add documentation field to the systemd unit

Forwarded: no
Last-Update: 2014-01-03

Gbp-Pq: Name haproxy.service-add-documentation.patch

Start after rsyslog.service

As HAProxy is running chrooted by default, we rely on an additional syslog
socket created by rsyslog inside the chroot for logging. As this socket cannot
trigger syslog activation, we explicitly order HAProxy after rsyslog.service.
Note that we are not using syslog.service here, since the additional socket is
rsyslog-specific.
Forwarded: no
Last-Update: 2017-12-01

Gbp-Pq: Name haproxy.service-start-after-syslog.patch

Use dpkg-buildflags to build halog

Forwarded: no
Last-Update: 2013-07-02

Gbp-Pq: Name 0002-Use-dpkg-buildflags-to-build-halog.patch

haproxy (2.2.5-2) unstable; urgency=medium

  * Upload to unstable.

[dgit import unpatched haproxy 2.2.5-2]

Import haproxy_2.2.5-2.debian.tar.xz

[dgit import tarball haproxy 2.2.5-2 haproxy_2.2.5-2.debian.tar.xz]

Import haproxy_2.2.5.orig.tar.gz

[dgit import orig haproxy_2.2.5.orig.tar.gz]

Merge haproxy (2.0.19-1) import into refs/heads/workingbranch

Add documentation field to the systemd unit

Forwarded: no
Last-Update: 2014-01-03

Gbp-Pq: Name haproxy.service-add-documentation.patch

Start after rsyslog.service

As HAProxy is running chrooted by default, we rely on an additional syslog
socket created by rsyslog inside the chroot for logging. As this socket cannot
trigger syslog activation, we explicitly order HAProxy after rsyslog.service.
Note that we are not using syslog.service here, since the additional socket is
rsyslog-specific.
Forwarded: no
Last-Update: 2017-12-01

Gbp-Pq: Name haproxy.service-start-after-syslog.patch

Use dpkg-buildflags to build halog

Forwarded: no
Last-Update: 2013-07-02

Gbp-Pq: Name 0002-Use-dpkg-buildflags-to-build-halog.patch

haproxy (2.0.19-1) unstable; urgency=medium

  * New upstream release.
    - BUG/MAJOR: mux-h2: Don't try to send data if we know it is no longer
                 possible

[dgit import unpatched haproxy 2.0.19-1]

Import haproxy_2.0.19.orig.tar.gz

[dgit import orig haproxy_2.0.19.orig.tar.gz]

Import haproxy_2.0.19-1.debian.tar.xz

[dgit import tarball haproxy 2.0.19-1 haproxy_2.0.19-1.debian.tar.xz]

Merge haproxy (2.0.18-1) import into refs/heads/workingbranch

Add documentation field to the systemd unit

Forwarded: no
Last-Update: 2014-01-03

Gbp-Pq: Name haproxy.service-add-documentation.patch