--send-same-http-code=false considered harmful

[SISheogorath]

After upgrading to v3, I noticed that some of my pages, running behind oauth2-proxy in combination with ingress-nginx were experiencing strange problems. API calls would fail, some things wouldn't be rendered correctly.

After manually calling the sign-in URL from oauth2-proxy it worked again.

When I started to investigate, I realised that the problem was that the defaultbacked for ingress-nginx was called and returned a error code 200, when oauth2-proxy returned a 401, which should trigger a redirect to the sign-in URL.

As a result various pages, that were considered protected by oauth2-proxy were exposed to the public web.

This is not a security vulnerability in either of the projects, but an easy mistake to make when following official documentation, like here: https://kubernetes.github.io/ingress-nginx/user-guide/custom-errors/ (even stating that changing the error codes is bad)

In combination with: https://kubernetes.github.io/ingress-nginx/examples/auth/oauth-external-auth/#overview

As a workaround, I highly recommend anyone using these error-pages to change the parameters of this image. When using the ingress-nginx helm chart it would look like this, with the focus on extraEnvs:

defaultBackend:
  enabled: true
  image:
    repository: ghcr.io/tarampampam/error-pages
    tag: 3.3.2
  extraEnvs:
    - name: SEND_SAME_HTTP_CODE
      value: "true"

What would I like to discuss: Is changing the HTTP code by default maybe a bad idea?

[tarampampam]

Hey, thanks for the detailed write-up - this is a real footgun, and I appreciate you documenting it clearly.

The reason the default is 200 (and likely will stay that way) is that error-pages is used in two fundamentally different roles:

1. As defaultBackend - where error-pages itself sends the final response to the client. Here you must set --send-same-http-code / SEND_SAME_HTTP_CODE=true.
2. As a custom error page backend (via proxy_intercept_errors / error_page in nginx, handle_response in Caddy, errors middleware in Traefik) - where the proxy intercepts the upstream response, fetches the error page internally, and sends its own status code back to the client. In this case, the 200 from error-pages is intentional and expected.

These two setups have opposite requirements, which is why the safe default isn't obvious.

That said, your concern is well taken - using defaultBackend without --send-same-http-code is a silent footgun that breaks oauth2-proxy, auth middlewares, and anything else relying on the HTTP status code.

This is now prominently documented in v4 (just released today), specifically in the ingress-nginx guide:

error-pages/docs/guides/k8s_ingress_nginx.md

Lines 206 to 208 in 11aebaa

	Setting **`config.sendSameHttpCode=true`** is critical for the ingress-nginx integration - error-pages must return
	the same HTTP status code as the error it renders, not `200`. Otherwise, ingress-nginx will proxy the `200`
	response to the client and the actual error code will be lost.

[SISheogorath]

I appreciate the update, but it might be a bit too late for ingress-nginx. It got retired by the end of march: https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/

[tarampampam]

Yes, I also found out about this quite recently, and, to be honest, it was a bit disappointing. It reminds me somewhat of the situation with gorilla/websocket, so perhaps things could still change - I'd like to hope so.

In any case, I've written several guides on integrating with other routers (you can find them here, hopefully, some of them will be useful)