Skipper: kubeclient: Return 502 instead of 404 if route is not configured.

[mikkeloscar]

If you make a request with a hostname that is not configured in skipper you currently get a 404 i.e. a client error.
In reality it is more likely to be a server error that the route wasn't configured and thus the correct response should be 502 - Bad gateway.

[aryszka]

i don't completely agree.. we must consider other use cases and not only our own ones.

i get that part that in order to reach skipper ingress, the lb must have been already found by the dns before. But this is also not necessarily true, because it is also possible that the lb or the dns is misconfigured and it's not a server issue at all.

While I am pretty much against it and believe that 404 is the best approach with all possible users and use cases in mind, maybe we can do something like this:

• when a route is not found at all, respond with 502
• for ingresses that don't specifiy a catchall ("/"), generate an additional catchall for the host, which when is found, responds with 404 (using the status(404) filter)

This behavior, if implemented, should be explicitly enabled with a command line flag.

[mikkeloscar]

because it is also possible that the lb or the dns is misconfigured and it's not a server issue at all.

I would say that from a client PoV it does not matter if it's the dns or the server that is misconfigured. Something is wrong and it's not the client's fault, and skipper is the only component (when used as ingress) which can respond with something.

maybe we can do something like this:

• when a route is not found at all, respond with 502
• for ingresses that don't specifiy a catchall ("/"), generate an additional catchall for the host, which when is found, responds with 404 (using the status(404) filter)

Yup, I agree this would be the way to do it!

This behavior, if implemented, should be explicitly enabled with a command line flag.

Indeed

[aryszka]

I would say that from a client PoV it does not matter if it's the dns or the server that is
misconfigured. Something is wrong and it's not the client's fault, and skipper is the only
component (when used as ingress) which can respond with something.

this is a good argument. I was thinking in terms of chain of proxies/LB/andwhatnot, but you think from the point of view of the end client. OK, we can do it.