Also +1... if STEERING is simply a subset of CLIENT_STEERING features, then no real point in keeping both.
I will admit, however, that the `?format=json` thing sort of bothers me. We have run into at least 1 case that I know if where that conflicted with a customer's app, which was also making use of the `format` query string. __Jason On Thu, May 2, 2019 at 1:55 PM Derek Gelinas <mrdgeli...@gmail.com> wrote: > I'm definitely +1 on this. Good idea! > > > On May 2, 2019, at 9:32 AM, Jeremy Mitchell <mitchell...@gmail.com> > wrote: > > > > Good suggestion, Rawlin. > > > > +1 I'm always in favor of any sort of simplification and this sounds > like a > > good one. As always, I'd suggest creating an issue ( > > https://github.com/apache/trafficcontrol/issues) and put your > explanation > > in there and we can mark it as "tech debt" and hopefully we can find the > > time to get it done. > > > > > > > > On Wed, May 1, 2019 at 6:41 PM Dave Neuman <neu...@apache.org> 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 <rawlin.pet...@gmail.com> > >> 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 > >>> > >> > >
