HAProxy reqadd, rspadd and reqirep were removed

The fix/etc/haproxy/haproxy.cfg

# Old (removed in 2.1 — will not start)
#   rspadd  X-Frame-Options:\ DENY
#   reqideny ^User-Agent:.*sqlmap
#
# Current
    http-response set-header X-Frame-Options DENY
    http-request deny if { req.hdr(user-agent) -m sub sqlmap }

If you see this

[ALERT] parsing [/etc/haproxy/haproxy.cfg:42] : The 'reqirep' directive is not supported anymore since HAProxy 2.1. Use 'http-request replace-header' instead.

A fatal parse error, not a warning. The directive was removed, so the process refuses to start until the line is replaced or deleted. — haproxy/src/cfgparse-listen.c

[ALERT] parsing [/etc/haproxy/haproxy.cfg:42] : The 'rspadd' directive is not supported anymore since HAProxy 2.1. Use 'http-response add-header' instead.

The same removal. rspadd is how nearly every pre-2020 guide adds security headers, which is why this is the one people hit while hardening. — haproxy/src/cfgparse-listen.c

This page exists because the failure is loud but the advice is quiet: the config won’t start, the operator deletes the offending line to get the service back, and the control it was implementing quietly disappears with it.

What happened

Before 2.1, HAProxy manipulated HTTP headers with a family of regex directives operating on raw header lines: reqadd, reqrep, reqdel, reqdeny, reqallow, reqtarpit, their case-insensitive reqi* twins, and the rsp* equivalents for responses.

HAProxy 2.1 removed all of them. Not deprecated with a warning — removed, as a fatal parse error that names the replacement. The reason is the HTX engine: HAProxy now parses HTTP into a structured internal representation shared by HTTP/1, HTTP/2 and HTTP/3, and rules that ran a regex over a raw header line no longer have a raw header line to run over.

This matters for hardening specifically because rspadd was the documented way to add security headers for about a decade, and reqideny was how guides blocked scanners and bad user agents. A large fraction of HAProxy hardening material written before 2020 is now a config that does not boot.

The translation table

Removed	Use instead
reqadd	http-request add-header
reqrep / cliexp	http-request replace-path, replace-uri or replace-header
reqirep	http-request replace-header
reqdel / reqidel	http-request del-header
reqdeny / reqideny	http-request deny
reqallow / reqiallow	http-request allow
reqtarpit / reqitarpit	http-request tarpit
reqpass / reqipass	(no replacement — it did nothing but stop rule processing)
rspadd	http-response add-header
rsprep / rspirep	http-response replace-header
rspdel / rspidel	http-response del-header
rspdeny / rspideny	http-response deny

HAProxy prints the right-hand column in the error itself, which makes the translation mechanical. The one worth pausing on is add-header versus set-header: add-header appends another copy of the header even if one is already present, while set-header replaces any existing value. For security headers you almost always want set-header, because two conflicting X-Frame-Options headers is a worse outcome than either one alone — and the literal replacement HAProxy suggests for rspadd is add-header.

Two related deprecations

Not removals, but they show up in the same old configs:

• option httpclose and the long-gone option forceclose — connection handling was reworked; option http-server-close or the default keep-alive behaviour is what you want now.
• option accept-invalid-http-request was renamed to option accept-unsafe-violations-in-http-request (and the response equivalent likewise). The rename is deliberate: the old name sounded like a compatibility toggle, and the new one says what it is. It relaxes HTTP parsing strictness, which is directly relevant to request smuggling — leave it off unless you have a specific broken client and understand what you are accepting.

Verify it worked

The check is simply whether the config parses:

haproxy -c -f /etc/haproxy/haproxy.cfg

Expect Configuration file is valid. Any removed directive produces an [ALERT] naming the line and its replacement.

To find them before you upgrade — which is the useful order — scan for the whole family:

grep -nE '^\s*(req|rsp)i?(add|rep|del|deny|allow|pass|tarpit)\b' \
  /etc/haproxy/haproxy.cfg

An empty result means the config is already on modern syntax.

Then confirm the controls those lines were implementing still exist. A config that parses is not evidence that the security header survived the migration:

curl -sSI https://your-site.example/ | grep -iE 'x-frame-options|strict-transport|x-content-type'

Before you apply this

The risky moment is not the upgrade — it is the fix. HAProxy refuses to start, production is down, and the fastest way to get it back is to delete the lines it is complaining about. That works, and it silently removes whatever those lines were enforcing.

Translate rather than delete. If you are under time pressure, comment the old line out next to its replacement so the intent survives:

#   rspadd  X-Frame-Options:\ DENY      # removed in 2.1
    http-response set-header X-Frame-Options DENY

Check before the upgrade, not after:

haproxy -c -f /etc/haproxy/haproxy.cfg   # using the NEW binary, old config

-c parses and exits without binding ports or touching the running process, so it is safe to run against a live server’s config with a newer binary in place.

Related

• Add security headers in HAProxy — what rspadd was usually doing.
• Request smuggling — why parsing strictness options matter.