Support a ResponseBodyModifier filter

[arkodg]

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 response

Why this is needed:
To return a more informative and visually pleasing response whenever errors such as 404 or 5XX are encountered in the data plane or backend

NGINX 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/

[howardjohn]

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

[arkodg]

@howardjohn this is specific to return a custom response based on bad statuses (like 5XX)
linking some open issues from users in other implementations

• Istio - Customized Error response in case of origin authentication failure  istio/istio#10543
• Contour - Ability to specify custom error page projectcontour/contour#320

[howardjohn]

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.

[arkodg]

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

[howardjohn]

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 <#1998 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEYGXI7LQJP4DNKRWVULODXEVKBTANCNFSM6AAAAAAXXPALH4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[arkodg]

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

[RWDai]

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:

• Response body needs to be encrypted
• Response body needs to be compress

[shaneutt]

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.

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted