request help: Distinguish the source (upstream or apisix) of the status code, whether it can be extended to all the status code

[fukiki]

Issue description

There was a discussion earlier about How to distinguish the source of these response status codes :
Issue 2501 and PR 2817.

The conclusion is that: In the response header of the request, through the response header of X-APISIX-Upstream-Status, we can effectively identify the source of the 5xx status code.

About this, I have a question: Why only distinguish 5xx status codes?

In some scenarios, the requirement may be how to distinguish the source of status codes 4xx.

In addition to this, We can rewrite the upstream status codes by APISIX's response-rewrite plugin. In this case, if we can't distinguish the source of the status code，upstream or apisix，it can’t quickly help us determine the problem.

Therefore, I would like to ask for some opinions of the community：
Distinguish the source (upstream or apisix) of the status code, whether it can be extended to all the status code，not only 5xx.

[Firstsawyou]

Why only distinguish 5xx status codes?

There are many factors that cause 5xx status codes. We need to distinguish their sources and narrow the scope of the problem. The 4xx status codes are caused by client requests that do not conform to semantic specifications and have obvious prompt information.

[fukiki]

Why only distinguish 5xx status codes?

There are many factors that cause 5xx status codes. We need to distinguish their sources and narrow the scope of the problem. The 4xx status codes are caused by client requests that do not conform to semantic specifications and have obvious prompt information.

The 4xx status codes are not only caused by client requests, such as the following example：

[Firstsawyou]

The 4xx status codes are not only caused by client requests, such as the following example：

This is more intuitive to know the cause of the problem. Maybe we need to support distinguishing the source of 4xx status codes.

[fukiki]

This is more intuitive to know the cause of the problem. Maybe we need to support distinguishing the source of 4xx status codes.

In some special cases, other status codes may have similar problems.
Support distinguishing the source of all status codes, will be more generic.

[tokers]

Actually, there are a bunch of headers can be added for the debugging purpose:

• X-Upstream-Status, the status code returned by upstream;
• X-Upstream-Addr, the upstream endpoint address;
• ....

Of course, some information is sensitive, and maybe a switch should be introduced to show these data.

[fukiki]

Actually, there are a bunch of headers can be added for the debugging purpose:

• X-Upstream-Status, the status code returned by upstream;
• X-Upstream-Addr, the upstream endpoint address;
• ....

Of course, some information is sensitive, and maybe a switch should be introduced to show these data.

@tokers That's a good suggestion.

[imjoey]

@fukiki @Firstsawyou @tokers

As the X-APISIX-Upstream-Status is already supported, so I was wondering that is that possible for us to reach a conclusion that adding X-APISIX-Upstream-Status back to the response header for all cases, under the control of a switch.

Thanks.

[Firstsawyou]

@fukiki @Firstsawyou @tokers

As the X-APISIX-Upstream-Status is already supported, so I was wondering that is that possible for us to reach a conclusion that adding X-APISIX-Upstream-Status back to the response header for all cases, under the control of a switch.

Thanks.

This looks good, I think it is ok.

[tokers]

We can send a proposal to the mail list, who wants to do this?

[imjoey]

We can send a proposal to the mail list, who wants to do this?

Hi @fukiki , is that possible for you to send a proposal email to the dev mail list for further discussion? We actually need more opinions. Thanks.

[fukiki]

@tokers @imjoey I will send a proposal email to the dev mail list for further discussion.

[gxthrj]

I think recording all non-2xx requests and provide a similar header of x-upstream-status is better.

[spacewander]

@liangliang4ward
Would you like to submit a PR for it?

[liangliang4ward]

I think recording all non-2xx requests and provide a similar header of x-upstream-status is better.

ok, let me try do this