Support for range based header matching while routing requests

[kavyako]

We have a requirement to perform header match if the value of a header is within a given range.

Today, route match happens based on the header's value (exact string comparison or regex matching). Can we add range as a third option there?

Something like: In the route config, headers section, range is specified as the lowKey and highKey. A match will happen if the header's value in the incoming request lies within the range.

Some options to implement this:

1. Range is specified in the route headers value field as a comma delimited string of the form "lowKey,highKey" and the range entry is true. 'range' is false by default. . Example below, if the incoming request contains a header PartitionKey:5, this route is matched.

{
"name": "PartitionKey",
"value": "1,10",
"regex": false,
"range": true
}

2. Another option is to have value as a JSON object and add a valueType entry which can be set to default, regex or range. When 'valueType='regex|default value is a string.

{
"name": "PartitionKey",
"value": {"low":1,"high":10},
"valueType": "range",
"regex": false, // possibly deprecate in the future
}

This will be a breaking change though.

Would love to hear any other suggestions as well. If we have consensus on the approach, I can take a stab at adding this support.

[mattklein123]

In general it would be great if we could make this a v2 only feature. That would involve Iterating on this proto: https://github.com/envoyproxy/data-plane-api/blob/master/api/rds.proto#L808. It's unfortunate we did not use oneof there (this has already been brought up). I would suggest that we actually do this now, and deprecate the existing value and regex field. (oneof will basically create the appropriate enum). cc @wora @htuch

For the feature itself, I would rather the range stuff be strongly typed integers in proto, and then it seems fine to me. If you want to do the data-plane-api PR we can discuss further there.

[kavyako]

Actually we are still using the v1 APIs here so will want the range support in v1 too. I have the changes with oneof implemented for v2 APIs.
Now looking at updating the v1 config schema for this.
What is the general protocol while updating the v1 config? Are breaking changes allowed (i.e use oneof there as well) or shall I add new fields in the config json for the range low, high and isRange and make this an additive change?
Will start a PR once I have everything working with the tests.

[mattklein123]

@kavyako breaking changes are not allowed, so if you need v1 support the change must be additive. Please also make sure you have both v1 and v2 docs when you do your data-plane-api change. Thank you!

[mattklein123]

This is done.