disable custom error page for some specific ingress when global custom error page is enabled

[lwabish]

I have enabled custom error page globally by following custom-errors.
But some workload in kubernetes needs the original error response to work correctly.So I have to disable custom error page for some ingress.
From what I can gather based on my research of official documentation and search engine results, it appears that currently the only way to override specific status codes from the global custom HTTP error settings is by setting the nginx.ingress.kubernetes.io/custom-http-errors annotation for the ingress.
However, it seems that it is not possible to completely disable custom http errors for some ingress when custom error page is configuared globally.
Do we need to add this feature?

[k8s-ci-robot]

This issue is currently awaiting triage.

If Ingress contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[longwuyuan]

Can you please write a step-by-step instruction set, so that a reader here can copy/paste from your instructions, into a cluster created with kind and reproduce the problem. Thnx

[github-actions]

This is stale, but we won't close it automatically, just bare in mind the maintainers may be busy with other tasks and will reach your issue ASAP. If you have any question or request to prioritize this, please reach #ingress-nginx-dev on Kubernetes Slack.

[lwabish]

Ok, I will describe the problem I met and the current workaround about it.

1. prepare a kubernetes cluster(in my case the cluster version is 1.21)
2. install ingress-nginx with the lead of this repo(in my case version 1.3.1, chart version 4.2.5)
3. install some custom error page module and configure ingress-nginx to enable custom error feature, according to this example
4. once the 3 steps above are done, if we visit some url by ingress and the response is not 200, for example we can test it with 404 response, we can see some custom error page instructing users the errors.
5. install minio with helm(app version 5.0.7)
6. visit minio domain with the help of ingress, the anonymous visit returns status code 403 and some xml in response orginally, now it returns custom page like 4xx html, which could lead to minio logic failure because it parses the xml in response to work properly.

To tune the configuration of ingress about custom error feature, I found an annotation about it called nginx.ingress.kubernetes.io/custom-http-errors, which is a whitelist of status codes to use custom error, which means I currently can't disable custom error feature per ingress.

By searching information about the annotation above, I have found some information saying that setting nginx.ingress.kubernetes.io/custom-http-errors to blank string could disable the custom error for the whole ingress object, but aftering trying and dive into the code , I found it not working.

So my current workaround is choosing a status code which is never used by minio and annotate the minio ingress , like nginx.ingress.kubernetes.io/custom-http-errors: '599', but not quite elegant.

Also, I just found a similar issue: #8384

[longwuyuan]

What you found is true and inside the nginx.conf, it relates to the nginx directives.

What you expect is fair a justified. But it involves doing work that is unprecedented and customized for user experience rather than for aligning to easy use of the directives in nginx.conf. Many other users have created customized default backends so that they can control what response they send. This seems like the only reasonable alternative available today.

The project is short on resources and in fact deprecating features that are popular but need too much support/maintenance. Whatever dev time available is being focused on security & Gateway-API implementation. So there is not much chance that this will be worked on anytime in the near future. If others want to contribute, it would be a welcome PR and get reviewed.

As such this issue is not tracking any action item yet adding to the tally of open issues. I will close this for for now and when a action item gets updated here, then the issue can be re-opened.

/close

[k8s-ci-robot]

@longwuyuan: Closing this issue.

In response to this:

What you found is true and inside the nginx.conf, it relates to the nginx directives.

What you expect is fair a justified. But it involves doing work that is unprecedented and customized for user experience rather than for aligning to easy use of the directives in nginx.conf. Many other users have created customized default backends so that they can control what response they send. This seems like the only reasonable alternative available today.

The project is short on resources and in fact deprecating features that are popular but need too much support/maintenance. Whatever dev time available is being focused on security & Gateway-API implementation. So there is not much chance that this will be worked on anytime in the near future. If others want to contribute, it would be a welcome PR and get reviewed.

As such this issue is not tracking any action item yet adding to the tally of open issues. I will close this for for now and when a action item gets updated here, then the issue can be re-opened.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.