Conditional custom responses for internal errors

The request is to make http-after-response return exist, mirroring what http-response return already does for backend responses, so that HAProxy's own generated errors can be rewritten conditionally. Start by tracing how http-response return is parsed and executed versus the rules allowed in the http-after-response rule set, since the gap between them is the whole issue. A useful sanity check is the 204 workaround in the report: the new directive should let the same config drop the set-status/del-header/set-header dance without HAProxy forcing Connection: close. Done means the keyword is accepted, documented and covered by a config regression test.

Your Feature Request

Hi! At the moment it does not seem possible to conditionally change the response for HAProxy internally generated errors depending on an ACL in a robust way. For backend server errors there is http-response return, but there is no http-after-response return and both http-error and errorfile do not support if. Having a proper http-after-response return would allow changing all responses the client sees in a consistent way.

The best workaround at the moment seem to be http-after-response set-status with http-after-response del-header which has some strange effects on the Content-Length header / closing connection for 204 status:

when http-after-response set-status 204 is used and Content-Length header is removed (it has to be removed as otherwise a non-zero Content-Length would be in the response) HAProxy adds Connection: close and closes the connection, minimal example:

$ cat haproxy.cfg
defaults
  mode http
  http-reuse always
  timeout client 30s
  timeout server 30s
  timeout connect 30s

frontend http
  bind :8080
  default_backend backend

  http-after-response set-status 204
  http-after-response del-header ^.* -m reg

backend backend

$ curl -v localhost:8080
...
> GET / HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/8.19.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 204 No Content
< connection: close
<
* shutting down connection #0

to prevent it from closing the connection http-after-response set-header Content-Length 0 can be used, which somehow works, but is an incorrect http response according to MDN ("Note that the response must not include any content or the Content-Length header (browsers may reject responses that include content)."), minimal example:

$ cat haproxy.cfg
defaults
  mode http
  http-reuse always
  timeout client 30s
  timeout server 30s
  timeout connect 30s

frontend http
  bind :8080
  default_backend backend

  http-after-response set-status 204
  http-after-response del-header ^.* -m reg
  http-after-response set-header content-length 0

backend backend

$ curl -v localhost:8080
...
> GET / HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/8.19.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 204 No Content
< content-length: 0
<
* Connection #0 to host localhost:8080 left intact

What are you trying to do?

I would like to change response to 204 depending on the status as well as other conditions, like source ip, while keeping the connection open as much as possible. At the moment, the best option seem to be:

defaults
  mode http
  http-reuse always
  timeout client 30s
  timeout server 30s
  timeout connect 30s

frontend http
  bind :8080
  default_backend backend

  http-response set-var(res.set204) int(1) if { status ge 400 } !{ src 127.0.0.1 }
  http-response return status 204 errorfile ./204.http if { var(res.set204) -m int eq 1 }

  # Unfortunately http-after-response cannot be used above and to change internal errors we need:
  http-after-response set-var(res.set204) int(1) if { status ge 400 } !{ src 127.0.0.1 }
  http-after-response set-status 204 if { var(res.set204) -m int eq 1 }
  http-after-response del-header ^.* -m reg if { var(res.set204) -m int eq 1 }  # otherwise a non-zero content-length could end up in the response
  http-after-response set-header Content-Length 0 if { var(res.set204) -m int eq 1 }   # invalid according to MDN but looks like the only way to prevent HAProxy from closing the connection

backend backend
  server s1 127.0.0.1:8001 check

Output of haproxy -vv

I tried the current master and 3.2.19, master version:

HAProxy version 3.5-dev1-ff6bb3-19 2026/06/30 - https://haproxy.org/
Status: development branch - not safe for use in production.
Known bugs: https://github.com/haproxy/haproxy/issues?q=is:issue+is:open
Running on: Linux 6.1.0-49-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.174-1 (2026-05-26) x86_64
Build options :
  TARGET  = linux-glibc
  CC      = cc
  CFLAGS  = -O2 -g -fwrapv -fvect-cost-model=very-cheap
  OPTIONS =
  DEBUG   =

Feature list : -51DEGREES +ACCEPT4 +BACKTRACE -CLOSEFROM +CPU_AFFINITY +CRYPT_H -DEVICEATLAS +DL -ECH -ENGINE +EPOLL -EVPORTS +GETADDRINFO +HAVE_TCP_MD5SIG -KQUEUE +KTLS -LIBATOMIC +LIBCRYPT +LINUX_CAP +LINUX_SPLICE +LINUX_TPROXY -LUA -MATH -MEMORY_PROFILING +NETFILTER +NS -OBSOLETE_LINKER -OPENSSL -OPENSSL_AWSLC -OPENSSL_WOLFSSL -PCRE -PCRE2 -PCRE2_JIT -PCRE_JIT +POLL +PRCTL -PROCCTL -PROMEX -PTHREAD_EMULATION -QUIC -QUIC_OPENSSL_COMPAT +RT +SHM_OPEN +SLZ -SSL -STATIC_PCRE -STATIC_PCRE2 +TFO +THREAD +THREAD_DUMP +TPROXY +TRACE -WURFL -ZLIB
Detected feature list : +HAVE_WORKING_TCP_MD5SIG

Default settings :
  bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with multi-threading support (MAX_TGROUPS=32, MAX_THREADS=1024, default=12).
Built with network namespace support.
Built with libslz for stateless compression.
Compression algorithms supported : identity("identity"), deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT IP_FREEBIND
Built without PCRE or PCRE2 support (using libc's regex instead)
Encrypted password support via crypt(3): yes
Built with gcc compiler version 15.2.1 20260214

Available polling systems :
      epoll : pref=300,  test result OK
       poll : pref=200,  test result OK
     select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Available multiplexer protocols :
(protocols marked as <default> cannot be specified using 'proto' keyword)
         h2 : mode=HTTP  side=FE|BE  mux=H2    flags=HTX|HOL_RISK|NO_UPG
  <default> : mode=HTTP  side=FE|BE  mux=H1    flags=HTX
         h1 : mode=HTTP  side=FE|BE  mux=H1    flags=HTX|NO_UPG
       fcgi : mode=HTTP  side=BE     mux=FCGI  flags=HTX|HOL_RISK|NO_UPG
  <default> : mode=SPOP  side=BE     mux=SPOP  flags=HOL_RISK|NO_UPG
       spop : mode=SPOP  side=BE     mux=SPOP  flags=HOL_RISK|NO_UPG
  <default> : mode=TCP   side=FE|BE  mux=PASS  flags=
       none : mode=TCP   side=FE|BE  mux=PASS  flags=NO_UPG

Available services : none

Available filters :
	[BWLIM] bwlim-in
	[BWLIM] bwlim-out
	[CACHE] cache
	[COMP] comp-req
	[COMP] comp-res
	[COMP] compression
	[FCGI] fcgi-app
	[SPOE] spoe
	[TRACE] trace