error-pages

error-pages copied to clipboard

Is there an existing issue for this?

• [X] I have searched the existing issues

Describe the problem to be solved

I have this setup as a default error handler on my k8s cluster, and it works great overall. My apis deployed on the cluster have a bit of an issue though.

When returning a 404 or something that this project is setup to respond for, my error content is ignored.

This turns my

{
    "error": "location_invalid",
    "message": "Given location either does not exist or is invalid."
}

Into

{
    "error": true,
    "code": "404",
    "message": "Not Found",
    "description": "The server can not find the requested page",
}

Suggest a solution

I propose modifying the error page to pull from the response body if it is provided

Something like

https://github.com/tarampampam/error-pages/blob/b8f9608992f78997de64058635f2ef7cd109ba3e/internal/http/core/errorpage.go#L56

props.Message =  string(ctx.Request.Body.Peek(Message))

I dont know go, so not sure if thats how it would be implemented.

This could be configured behind a bool for ALLOW_ERROR_MESSAGE_PASSTHROUGH which would default to false to maintain consistency with prior behavior.

Additional context

No response

I was just looking into this too. I use Traefik as my Ingress, so maybe nginx handles things differently. Unfortunately the error-middleware used to redirect to the error-page is a separate request and the original response is discarded. (see https://doc.traefik.io/traefik/middlewares/http/errorpages/)

There doesnt seem to be a way to only apply a middleware via a condition yet. So at this point i am unsure what options are left. A custom middleware should be able to do this i suppose.

Hello there, and thank you for bringing this issue to my attention! I'm currently working on a new major version of error pages, and I will address this as part of that update. When I have something ready for testing, I will notify you here. Please stay tuned!

@r2DoesInc Let's consider how we can address this. Based on my understanding (and as @Ruakij mentioned), Traefik handles error pages like a typical API gateway. If the downstream service returns an error code and has the errors middleware enabled, it fetches the response from the errors service and responds with that content. In this way, the errors service doesn't know anything about the original error content.

My question is whether the Nginx ingress works the same way. If it does, we can't forward the original response based on certain conditions. In that case, you would need to handle it at the ingress level. Am I correct, or am I missing something?

---

Update: To investigate exactly what your ingress is sending to the errors service, you can try to set up a tool like https://webhook.site/ as the errors service. This will allow you to observe the payload, headers, and other details. If successful, sharing some screenshots with the details would be greatly appreciated!

Off the top of my head I do not know the answer to that question.

I will absolutely do some debugging and get back to you with some of the information provided by that site. My schedule still hasnt opened up much but Ive added this to my task list.

Thats a nifty tool, thanks for sharing.

Can I close this issue?

@Ruakij - for traefik, I would create a separate ingressroute with a higher priority and no middleware to handle API requests.

When you have two IngressRoutes, only one of them will be used to serve a request. If the (more specific) IngressRoute with the higher priority matches a request, the other (more general) IngressRoute with the middleware will not be executed.