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
I agree with being vigilant with regards to the Perl. I am still on
board with forcing the Perl route handlers to return a 501 after being
rewritten, but we shouldn't do that in the same release as its
corresponding Go-rewritten route so that we'd still be able to
fallback easily to the Perl handle
> Not trying to sideswipe, but could we expose that as an endpoint with a
> Golang list as well to solve:
> 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
overcom
I'm +1 on this final summary. It infers that we are going to soon be adding a
job that runs CI checks on Master. This is good. That's probably a subject for
another thread. I do have one question about this approach. I think there is
probably a scenario where we need to fix an issue on the 4.x b
> I would propose that newly rewritten routes be added to this hardcoded
list in TO-Go. Then after being in one release as "Perl-routable", they
would become "non-Perl-routable" in the following release.
I'm a big +1, as long as we're extra-vigilant about this. More than
unroutable, we need to del
I'm +1 on this idea as well. Not too concerned about the implementation but
just having an easy way to "turn off" rewritten Go api routes and fall back
to the proven perl routes seems like a nice safety valve. In the past,
we've seen bugs creep in to the api rewrite and a quick off switch seems
ver
I am +1 on this idea.
On Fri, Nov 1, 2019 at 09:26 Gray, Jonathan
wrote:
> The available routes and what associated backend they go to are operator+
> sensitive information. I'd also lean towards a stronger degree of safety
> and only make it read-only.
>
> Jonathan G
>
> On 11/1/19, 8:41 AM,
The available routes and what associated backend they go to are operator+
sensitive information. I'd also lean towards a stronger degree of safety and
only make it read-only.
Jonathan G
On 11/1/19, 8:41 AM, "Hoppal, Michael" wrote:
I would be +1 on TO API routing blacklist.
I think
I would be +1 on TO API routing blacklist.
I think it is a great idea to allow us to continue to move fast while
minimizing risk.
I do agree we should expose the current state of the blacklist as an API
endpoint as to easily get insight into the current configuration. We could even
make the bl
