TCP traffic tapping doesn't support any matching other than "any"

[jphx]

I've been experimenting with TCP traffic tapping of an upstream cluster. E.g.,:

"transport_socket": {
    "name": "envoy.transport_sockets.tap",
    "typed_config": {
      "@type": "type.googleapis.com/envoy.extensions.transport_sockets.tap.v3.Tap",
      "common_config": {
        "admin_config": {
          "config_id": "mtu.hserver-multi-tenant-upstream.cerberus"
        }
      },
      "transport_socket": {
        "name": "envoy.transport_sockets.tls"
      }
    }
  },

This example uses the admin_config, but that's not important. My question concerns the static_config alternative as well. Continuing with the admin config example, however, if I post this document to the /tap endpoint, it captures traffic:

config_id: mtu.hserver-multi-tenant-upstream.cerberus
tap_config:
    match:
        any_match: true
    output_config:
        streaming: true
        sinks:
            - streaming_admin: {}

But if I post this document, with different match criteria, it never captures traffic, even when the header exists:

config_id: mtu.hserver-multi-tenant-upstream.cerberus
tap_config:
    match:
        http_request_headers_match:
            headers:
                - name: x-capture
                  present_match: true
    output_config:
        streaming: true
        sinks:
            - streaming_admin: {}

Possibly this is intentional. After all, I'm tapping at the TCP level, not the HTTP level. But the documentation doesn't say anything about matching (except for "any") not working when tapping at the TCP level. So I don't know if this is a bug or a documentation deficiency.

I tested with Envoy version

40de14954b29b4c1c87793482b90b27da3370f0f/1.17.0-dev/Clean/RELEASE/BoringSSL

[mattklein123]

Transport level tapping doesn't support HTTP matching. I think we can do 2 things here:

1. Better docs
2. Possibly fail if a configuration that we can't actually match on is specified.