request help: Support customizing the body when response exits

[nanamikon]

Issue description

Relate to #3528

I think we can add a feature to customize the body when response exits. For example, different format of json, even html
or xml , can be use to display the exit message

Refer to apisix/core/response.lua, resp_exit will be called when response exits, I think it is a global handle for response exiting, we can't use plugin extension here。 What about redirecting to a new uri to do the actual work ？

Add method

function _M.register_exit_handle_uri(uri){
       handle_uri = uri
}

Modify apisix/core/response.lua
Add exec to redirect to error handle

    if handle_uri then
        ngx.exec(handle_uri, {code=xxx, body=yyy});
    else
        if idx > 0 then
          ngx_print(concat_tab(t, "", 1, idx))
        end
    
        if code then
            return ngx_exit(code)
        end   
    end

Add new config to change this behavior

apisix:
      exit_handle_uri:"/error_handle"
     

New uri for error handle，added by http_server_configuration_snippet

    location = /error_handle {
      content_by_lua '
        local args = ngx.req.get_uri_args()
        ngx.print(args.body)
        return ngx.exit(args.code)
      ';
    }

Some discussion about kong

1 Kong error response
Kong/kong#3192

2 Upstream error response
Kong/kong#972

Environment

• apisix version (cmd: apisix version):2.2
• OS (cmd: uname -a):ubuntu 16
• OpenResty / Nginx version (cmd: nginx -V or openresty -V): 1.19
• etcd version, if have (cmd: run curl http://127.0.0.1:9090/v1/server_info to get the info from server-info API):3.4.17
• apisix-dashboard version, if have:

[spacewander]

I think we can do it.
@membphis
What's your opinion?

[nanamikon]

Refer to custom-error-pages feature provided by Ingress
https://kubernetes.github.io/ingress-nginx/user-guide/custom-errors/

Using a docker image as backend to deal with specific error code, and pass params through header

location @custom_upstream-default-backend_500 {
   internal;
   
   proxy_intercept_errors off;
   
   proxy_set_header       X-Code             500;
   proxy_set_header       X-Format           $http_accept;
   proxy_set_header       X-Original-URI     $request_uri;
   proxy_set_header       X-Namespace        $namespace;
   proxy_set_header       X-Ingress-Name     $ingress_name;
   proxy_set_header       X-Service-Name     $service_name;
   proxy_set_header       X-Service-Port     $service_port;
   proxy_set_header       X-Request-ID       $req_id;
   proxy_set_header       Host               $best_http_host;
   
   set $proxy_upstream_name upstream-default-backend;
   
   rewrite                (.*) / break;
   
   proxy_pass            http://upstream_balancer;
   log_by_lua_block {
    
    monitor.call()
    
   }
  }

I think we can use header too， and list all support headers in doc for extension

[spacewander]

Maybe we can implement a minimal version, just like your original reply. If we try to add too much things in a PR, there will be too much arguments.

[spacewander]

@nanamikon
PR is welcome!

[membphis]

I think we can do it.
@membphis
What's your opinion?

nice issue, we can support this feature

[nanamikon]

ok, I will submit a PR

[liangliang4ward]

hi, I wan't to know , this feat is support?

[leslie-tsang]

@qq54903099 AFAIK, the feature is still not supported yet, Would you like to have it a try ?
Here is a PR #4696 may help.

[spacewander]

Err...
@leslie-tsang
Now I think the #4696 can't solve the problem properly as we can't get the context in error_page.

I prefer the solution in #6040 (review)

But anyway, we should have a detailed discussion about the goal & the approach before we start.

[leslie-tsang]

Now I think the #4696 can't solve the problem properly as we can't get the context in error_page.

Ooh, thanks for pointing that out !

I prefer the solution in #6040 (review)
But anyway, we should have a detailed discussion about the goal & the approach before we start.

Agree.