I largely don't care about the blacklisted routes for this purpose. I really care about a conclusive list of whitelisted routes (for which the example json payload could be expanded to carry). It seems like we're solving the exact same issue from two directions. It permits each native client library to assert that the routes it expects and needs to exist, exist on the other side. I have no desire to actively modify the runtime routes (for security I don't think we every should), just to get the list of what it had at startup. Having the override config file on disk to switch on/off independent route/methods is something I'd expect to have to restart TO for (no different than changes in the cdn.conf). I do also agree with proper 503 handling, but it allows us to perform a basic sanity check to prevent half-completed workflows necessitating complex recovery paths. For applications that use the client SDK, it gives an easy handle to know if every single upgrade necessitates recompiling and deploying 3rd party applications, such as a CZF File generator.
Jonathan G On 11/1/19, 1:49 PM, "Rawlin Peters" <[email protected]> wrote: > Not trying to sideswipe, but could we expose that as an endpoint with a Golang list as well to solve: https://protect2.fireeye.com/url?k=5d57b4c9-01b3ba02-5d57937d-000babff3540-17d7cedf2908de8b&u=https://github.com/apache/trafficcontrol/issues/2872 While I do agree with the request for an API endpoint that tells the client what API versions are supported, I wouldn't want to overcomplicate *this* particular feature with an API endpoint to expose the information that is in the config file. If we implement that kind of "API information" API endpoint, I wouldn't be opposed to including the currently blacklisted routes in its response as a minor goal, but I don't really think it's warranted by this routing blacklist feature alone. You should have a really, really good reason to blacklist a route or bypass a TO-Go route for the Perl, so this should be a (hopefully) relatively rare operation to begin with. I don't think it would be all that useful for API clients to be able to see the list of currently blacklisted APIs. The API client should be written to properly handle 503s whenever they occur, and to the client it shouldn't matter if the 503 is from the database being overloaded at the time or if the route is blacklisted. - Rawlin
