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
