EG should allow developer to define errors in Proxy Policy

[djesani]

At the moment, if a request is unauthorized or a service endpoint becomes unavailable, EG simply returns plain text responses, such as "UNAUTHORIZED" or "BAD GATEWAY".

EG should allow the developer to decide how the error is returned, for example a JSON response or a HTML response and gracefully fallback to the plain text errors if these are not defined by the developer.

[XVincentX]

The error handler is here

Not to sure how we can implement a declarative yet flexible error handler.

[dyrkow]

@XVincentX Hi, I had the same problem.

I need to always return the JSON.

How can I send an error (JSON obj) if not one condition.pattern does not match?

....

pipelines:

  api:
    apiEndpoints:
      - base
    policies:
      - proxy:

          - condition:
              name: pathMatch
              pattern: '/serviecName/*'
            action:
              serviceEndpoint: someService

          - condition:
              name: pathMatch
              pattern: '/serviceName/*'
            action:
              serviceEndpoint: someService

[XVincentX]

@WebWorkDeveloper Your issue is not really connected to this one. This one is about customizing proxy errors — you just want to return a JSON payload in case something goes wrong.

We do not have a direct way to do that right now; you can use the expression policy to execute a small javascript code which can return the response you need.

[gmauricio]

@XVincentX I'm probably missing something but how would you use an expression to do this ? If I understand correctly there's no way to have access to the proxy error or proxied response out of the proxy policy implementation.
I've seen some gateways have a way to specify an "error page", for example: https://docs.traefik.io/middlewares/errorpages/#configuration-options.
They require you to host the "error page" but that might not be required in this case. I think the proxy could add an option to pass an errorMessage. Alternatively, is it possible to have an "errorAction" ? that might be more flexible, because you could use it to override status code and headers as well.