Clarification: rationale for returning HTTP 500 for invalid HTTPBackendRef

[ivanmatmati]

Hi,

I have a question about the rationale for returning HTTP 500 when an HTTPBackendRef is invalid (e.g. due to a missing ReferenceGrant, leading to RefNotPermitted).

The spec states that:

When a HTTPBackendRef is invalid, 500 status codes MUST be returned…

However, in this scenario:

• The client request is valid
• The backend may be healthy
• The failure is due to a routing/configuration constraint, not a runtime error

Using 500 could suggest an internal failure of the gateway, while 503 might suggest backend unavailability — neither seems to precisely reflect the situation.

Could you clarify:

• What was the motivation for choosing 500 here?
• Was this mainly for consistency across implementations?
• Were alternative status codes considered?

Thanks!

[youngnick]

The motivation was basically:

• 400-class errors are not correct, because the problem originates with an intermediate
• it has to be a 500 class error of some kind for the same reason
• There's no existing 500 class error that exactly matches
• So, we went with 500.

Mandating the exact error code is exactly because we want to ensure consistency across implementations, so that we can test in the conformance tests.

Alternative status codes were considered, but as I said above, were not suitable for various reasons.

[youngnick]

Oops, sorry, hit the wrong button and closed.

Overall, I'd summarize "Why 500?" as "It's not a client error, or a server error, it's a routing/proxy error, so 500 is the only viable option."

It's also imperative that we actually do return some error in these cases, because otherwise canary rollouts and weights would not have the desired effects.

[oktalz]

hi @youngnick

yes, some error, but 500 is literally its servers fault and server does not really know why 500 Internal Server Error - but we do know why -> grant does not allow it, its forbidden.

I'm not really sure we want to follow this, I know in advance people will complain that seeing 500 seems like something is wrong and it should be correct while in fact it is not allowed.

RefNotPermitted seems more like its unauthorized or forbidden (and you literally have Not Permitted in name and that is exactly that)

if user is not allowed to access it due to grants it is almost the same as having RBAC on some rest API, you do not get 500, you get 403 or 401 or something similar. Its not servers fault you do not get access to resource.