What should we add or change to make your life better?

There are scenarios to route based on a Header match modes:

NotContains
notContains: this is a modified NOT version of contains. This is not a strict NOT logic of contains rule because we want to maintains the AND relationships between items in the dictionary.

It will match only if the following are satisfied:

Header key does not exist.
For all header keys that exist, the value substrings are not found in header value.
In the example below, if request contains fooHeader: fooValue, barHeader: badValue, it would not be considered as match since foo is a substring of fooValue.

{
  "headers": {
    "notContains": {
      "fooHeader": "foo",
      "barHeader": "bar",
    }
  }
}

Psedocode would be

bool match = (!(headers?["fooHeader"].hasSubString("foo") ?? true) &&
              !(headers?["barHeader"].hasSubString("bar") ?? true))

AnyContains
anyContains: ALL header keys must be present. ANY one of the values for each of the header keys must be present as substring. All keys must have a substring matched.

{
  "headers": {
    "anyContains": {
      "fooHeader": [
        "foo1",
        "foo2"
        ],
      "barHeader": [
        "bar1",
        "bar2"
        ]
    }
  }
}

AnyValues
anyValues: ALL header keys must be present. ANY one of the values for each of the header keys must be present. All keys must have a value matched.

{
  "headers": {
    "anyValues": {
      "fooHeader": [
        "foo1Value",
        "foo2Values"
        ],
      "barHeader": [
        "bar1Value",
        "bar2Value"
        ]
    }
  }
}

Why is this important to you?

fairly common rules that teams would use when making routing decisions