Open arkodg opened 1 year ago
Do we really need it based on the response? And not just a static response based on request?
We are pretty quickly going to divulge into needing to do the ~full HTTPRoute matching on the response IMO, which is not great.
Even serving a static response is tricky. We don't want folks putting 10MB pages into YAML for example
@howardjohn this is specific to return a custom response based on bad statuses (like 5XX
)
linking some open issues from users in other implementations
Both of those issues are actually about customizing response codes return from the proxy for various things. The issue sounds like its asking to look at the backend's response to determine the response though?
Big difference, IMO, between customizing filter-driven responses and backend responses.
sure we can help the author, filter based on local reply or response from backend
some more error pages on the web to highlight the use case
Not necessarily saying we shouldn't do this, but as some more data points: the 404 case can be done today by providing a "match anything" ('default backend' in Ingress terms) that does whatever you want (in this case, return a 404 page)
On Fri, May 5, 2023 at 12:44 PM Arko Dasgupta @.***> wrote:
sure we can help the author, filter based on local reply or response from backend
some more error pages on the web to highlight the use case
- when I pass a bad path to Docker Hub - https://hub.docker.com/blah
- when I pass a bad path to Google - https://google.com/blah
— Reply to this email directly, view it on GitHub https://github.com/kubernetes-sigs/gateway-api/issues/1998#issuecomment-1536699806, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEYGXI7LQJP4DNKRWVULODXEVKBTANCNFSM6AAAAAAXXPALH4 . You are receiving this because you were mentioned.Message ID: @.***>
the default backend approach can handle these cases
but cannot handle these cases
the default backend approach can handle these cases
- route/rule to backend not found
but cannot handle these cases
- backend responded with 5XX probably because an internal method/API call timed out
- backend responded with a 404 because the resource wasn't found
and more case:
Sounds good, should be proposed as a GEP.
/triage accepted /kind gep
However we're currently focused on getting our GA release completed (see milestone v1.0.0) and this would not seem to be something that would need to block the release, so we're not ready to prioritize this and we would ask that v1.0.0 milestone issues get priority so we can focus there, and come back to this after the release.
This issue has not been updated in over 1 year, and should be re-triaged.
You can:
/triage accepted
(org members only)/close
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/
/remove-triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
What would you like to be added: A filter within
HTTPRoute
to allow the user to specify the configuration to return a custom response body based on the status code of the responseWhy this is needed: To return a more informative and visually pleasing response whenever errors such as
404
or5XX
are encountered in the data plane or backendNGINX supports this https://www.jajaldoang.com/post/nginx-custom-error-response/ Emissary (based on Envoy) supports this https://www.getambassador.io/docs/emissary/latest/topics/running/custom-error-responses HAProxy supports this https://www.haproxy.com/blog/serve-dynamic-custom-error-pages-with-haproxy/