There are multiple uses for opaque metadata that is associated with the
specific listener/filter chain/route that a request matches on:
1. Logging. Similar to header values, we can log the metadata values.
A listener might belong to a higher level concept in the
configuration language that generated LDS protos, e.g. there might be
a rule identifier expressed. This metadata allows logs to reflect the
rule identifier.
2. Future custom stats backends might use metadata to guide where and
how stats are emitted. E.g. the metadata might include information
about which stats collector to emit to.
3. Proprietary filters can receive additional inputs via the metadata.
The per-filter metadata generalizes and replaces the opaque_config in
RDS ForwardAction.
The metadata is structured such that each filter's metadata is under the
reverse DNS namespace defined by the filter. Shared metadata may be
arranged by coordinating on the reverse DNS namespace.
As an example, the "envoy.http_connection_manager.access_log" filter
namespace is suggested to be used for HTTP access logging.
Fixes#33.
SPKI doesn't change when certificate is reissued, so it works better
with short-lived certificates.
This is also the same format as used in HTTP Public Key Pinning.
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
As previously pointed out in #9, the empty string is not generally a useful
value in the xDS APIs, so can be be considered equivalent to an unset
field. This is now documented in principles in #28 as well.
Also replace google.protobuf.BytesValue with bytes.
This will be useful for Google and other site specific extension of the
resolving of both names and ports. For listeners, ports and bound
addresses can be expressed in a site-specific format. For upstreams,
host names can be resolved using the plugin.
htuch
Rohit Bhoj
Piotr Sikora
Harvey Tuch