Ah, I believe you are correct. I walked through the TR code and believe I can confirm that the "x-tc-steering-option" header and Steering Filter regexes are not supported in CLIENT_STEERING. So, there is a bit of functionality that would have to be added to CLIENT_STEERING in order to have a clean transition from a STEERING delivery service to a CLIENT_STEERING delivery service.
I think those operations could take precedent over the rest of the CLIENT_STEERING functionality if present. For instance, if the "x-tc-steering-option" header is present, just move that explicitly chosen target to the top of the result list. If the request path matches the STEERING_REGEXP for one of the targets, move that target to the top of the list. These operations could be mutually exclusive -- I'll have to dig into the STEERING code a bit more to figure out that behavior. Once I figure that out I will open a github issue with the "tech debt" label so that we can hopefully get to it in the future. - Rawlin On Wed, May 1, 2019 at 6:41 PM Dave Neuman <[email protected]> wrote: > > +1. I don’t think we actually use (old) steering anywhere in production. > Steering does support the regex feature (use a regex to “pin” to a DS) and > I don’t think the client_steering does, so we might want to consider moving > that feature into client_steering. Steering also supports an overwrite > header that may or may not be in client steering. > > On Wed, May 1, 2019 at 13:14 Rawlin Peters <[email protected]> wrote: > > > Hey all, > > > > I think we should consider deprecating the STEERING delivery service > > type in favor of CLIENT_STEERING. > > > > tl;dr: > > Everything that a STEERING delivery service provides can be provided > > by a CLIENT_STEERING delivery service instead, and CLIENT_STEERING > > provides more advanced features like Geolocation-based steering that > > are not available to the plain STEERING type. There are some small > > differences in request payloads when passing the `?format=json` query > > parameter, but other than that the client-facing interface is the same > > between CLIENT_STEERING and STEERING. > > > > What do you think of this proposal? Can you think of a good reason why > > we should keep STEERING in addition to CLIENT_STEERING? If you're > > skeptical or unsure, feel free to read the longer explanation below. > > > > > > Longer explanation: > > The main difference in the results returned by STEERING vs > > CLIENT_STEERING is that the STEERING result only contains the "top" > > target. This "top" target can still be returned as a json payload, as > > a 200 or a 302, depending on query parameters passed in the request, > > which is the same behavior as CLIENT_STEERING. However, > > CLIENT_STEERING will include *all* of the possible targets not just > > the "top" target. > > > > For clients that just consume and follow the 302, changing the > > delivery service from STEERING to CLIENT_STEERING won't really affect > > the clients -- that behavior would stay the same. However, if clients > > of the STEERING-type are passing `?format=json` in the request, that > > JSON payload differs slightly from STEERING to CLIENT_STEERING. > > > > For STEERING, the payload looks like this: > > {"location": "http://myedge.myds.mycdn.example.net/foo?format=json"} > > For CLIENT_STEERING, it uses an array like this: > > {"locations":["http://myedge.myds.mycdn.example.net/foo?format=json"]} > > > > For either STEERING or CLIENT_STEERING, if the client passes > > `?trred=false` to get a 200 response instead of a 302, the payload > > formats are the same. > > > > So, we couldn't really automatically convert all STEERING DSes to > > CLIENT_STEERING through a DB migration because of those small > > differences in the `?format=json` payloads between the two, but we > > could at least prevent the creation of new STEERING-type DSes during > > the deprecation period and encourage existing STEERING-type DSes to be > > converted to CLIENT_STEERING. Then after a major release or two we can > > draw a line in the sand and automatically convert STEERING types to > > CLIENT_STEERING, and/or make it a requirement that all STEERING-types > > must be converted to CLIENT_STEERING before a certain major release. > > > > Eliminating the STEERING type would allow us to simplify Traffic > > Router a little bit and make it less confusing for users by not having > > two different STEERING types to choose from. Going forward a lot of > > new features are only being added to the CLIENT_STEERING type because > > they don't really apply to STEERING, so the feature disparity between > > the two is only going to grow. > > > > - Rawlin > >
