No custom error page for non-standard status code

Help!
1

I would like to return non-standard status codes (like e.g. 419) in certain situations.

haproxy refuses to provide custom error pages for arbitrary status codes:

parsing [/etc/haproxy/haproxy.cfg:4] : errorfile : status code '419' not handled.

The idea is that when a user reports an error, I will then know what kind of action on haproxy has caused it.

How can I force haproxy to use whatever status code I want?

demo config:

frontend fe
  bind*:80
  mode http
  errorfile 419 /etc/haproxy/errors/419.http
  use_backend be
backend be
  mode http
  server localhost 127.0.0.1:80

Thanks

2

Haproxy does not return arbitrary error codes, so I don’t understand your request.

If you are in a conditional situation (that you can match with an haproxy ACL for example), you can already return whatever code and content that you want.

http-request return status 419 content-type text/plain lf-string "419 error bla" if { pathq /419uri }

Errorfiles never rewrite errors that come from backend servers, but only haproxy generated errors.

3

Maybe I did not make it clear enough what I’m trying to achieve.

The backend is not involved at all in this scenario.

For example, I may decide to use `http-request deny deny_status 419 if isquery_malicious`. In such a scenario, it’s not the backend sending status 419, but haproxy itself. I’d like to provide a custom error page in such a scenario. haproxy will let me provide custom error pages only if it “likes” the status code (e.g. 403, 404, 405, etc.). It seems that there is a predefined list of status codes, that haproxy will allow for that matter. If the desired (non-standard) status code is not on the list, a custom error page cannot be used.

The solution that you suggest does indeed work, but if the page should contain even simple CI (e.g. base64 encoded images, css), the config will get very messy and unreadable.

There is a very elegant solution in place (custom error pages), but it seems that haproxy won’t let me use it in my case.

4

http-request return allows pointing to files as well.

http-request return status 419 content-type text/html file /etc/haproxy/419.html if isquery_malicious

Errorfiles have a different use case not matching yours.

5

Many thanks! The suggested solution does exactly what I want.
However, I don’t understand why I can’t just use custom error pages, when I return an error.

Having to use a different mechanism seems unintuitive and over-complicated.

Also, the error page embeds the content-type in the errorfile, whereas when payload files are used, the content-type needs to be specified in the config, causing unnecessary clutter.

From my point of view, a feature request would make sense.