UPDATE - feat: clarify end-to-end semantics of http status codes - #872
UPDATE - feat: clarify end-to-end semantics of http status codes#872tfrauenstein wants to merge 1 commit into
Conversation
|
I strongly disagree with the sense of reality mentioned here. The majority of HTTP layer load balancers correctly return However, the case we are tackling with the targeted rule is exactly the case, where the router/load balancer is not part of the actual service, but an independent component with an independent failure behavior. For these cases the formulation of |
| == {MUST} be careful with interpreting 404 status code | ||
| Infrastructure components, like routers or proxies, may be configured | ||
| inconsistently not following the <<256>> guideline, and return {404} status code | ||
| instead of {503} when routes are missing. For example, the Kubernetes ingress | ||
| router https://github.com/zalando/skipper[Skipper] returns {404} per default | ||
| in case of missing routes. | ||
|
|
||
| Clients cannot generally rely on {404} representing the backend application resource | ||
| state. Depending on the network environment, clients must be careful with how to | ||
| interpret {404} error responses and may need to exclude e.g. routers as error source | ||
| via tests and inspection of router response headers or log information. |
There was a problem hiding this comment.
I actually do not understand we do here about how Skipper behaves by default, since we actually do not need to change the default behavior of skipper, which is still correct when it is used inside a service as router, we just need to change how our skipper-ingress deployment behaves within Kubernetes/EKS.
For me such a change - of which we know that it represents a broken behavior - sounds much simpler and cheaper than to make all clients ware of this mis-behavior and inspecting routing headers.
Update of Tronje's PR feat: clarify end-to-end semantics of http status codes (#864).
As discussed in Tronje's PR thread, this PR anticipates infrastructure reality of returning 404 in case of missing routes. The rule is changed to SHOULD and a MUST rule for clients is added. This PR is an update of the original PR.