Re: HTTP error code when route not found


Shannon Coen
 

Hello John,


The root of the issue is that because Gorouter receives configuration for both container scheduling and routing from Diego, it can't tell the difference between an app that is crashing and one that is deleted or unmapped from the route. 

Achieving a more intuitive behavior has required a significant architectural change that we have put off in favor of features with higher benefit-to-cost ratio. Our integration with Istio gives us the opportunity redesign how the routing subsystem receives config from the rest of the platform. We intend that Envoy will return a 503 when an app is stopped or crashing. For details, see https://docs.google.com/document/d/1VldkvgWPUh13o5RCNjSvzoPFhbY9BtLqBDdk2k0z9fw/edit

Gorouter currently returns a 502 when it has backends for a route in its routing table, but it cannot establish a TCP connection to one of them after three tries. We will likely persist this behavior in our integration with Envoy.

Best,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Tue, Feb 20, 2018 at 10:27 AM, Dieu Cao <dcao@...> wrote:
The routing team I believe is considering this use case in the new routing control plane proposal as outlined in https://lists.cloudfoundry.org/g/cf-dev/message/7717

-Dieu

On Fri, Feb 16, 2018 at 9:26 AM, Mike Youngstrom <youngm@...> wrote:
Here is a thread from the past that might help: https://lists.cloudfoundry.org/g/cf-dev/message/4503

Mike

On Fri, Feb 16, 2018 at 3:50 AM, John Mcteague <john@...> wrote:
When a route is not found by the gorouter, clients receive a http 404, which can be confusing for some downstream clients as its hard to distinguish between the resource in my app is not found vs the entire app is not found.

502 bad gateway is used in CF when the route is known but it is temporarily unable to reach the app backend.

Is there any thought on changing the error the gorouter returns in this scenario to help provide clients more meaningful information.Checking the X-cf-routererror header (which returns unknown_route) is not desirable as this starts to bake in CF specific behaviours into applications.

Thanks,
John




Join {cf-dev@lists.cloudfoundry.org to automatically receive all group messages.