[READ ONLY MIRROR] Envoy REST/proto API definitions and documentation. (grpc依赖)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

22 lines
736 B

tap: introduce HTTP tap filter (#5515) This is a MVP for the HTTP tap filter. It includes minimal infrastructure for the following: 1. Generic tap configuration which in the future will be used for static config, XDS config, etc. In this MVP the tap can be configured via a /tap admin endpoint. 2. Generic output configuration which in the future will be used for different output sinks such as files, gRPC API, etc. In this MVP the tap results are streamed back out the /tap admin endpoint. 3. Matching infrastructure. In this MVP only matching on request and response headers are implemented. Both logical AND and logical OR matches are possible. 4. In this MVP request/response body is not considered at all. 5. All docs are included and with all the caveats the filter is ready to use for the limited cases it supports (which are likely still to be useful). There is a lot of follow on work which I will do in subsequent PRs. This includes: 1. Merging the existing capture transport socket into this framework. 2. Implementing body support, both for matching on body contents as well as outputting body data. 3. Tap rate limiting so too many streams do not get tapped. 4. gRPC matching. Using reflection and loaded proto definitions, it will be possible to match on gRPC fields. 5. JSON matching. If the body parses as JSON, we can allow matching on JSON fields. Part of https://github.com/envoyproxy/envoy/issues/1413. Signed-off-by: Matt Klein <mklein@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ cf80045587240d494e54e9772949bc9af5eda61f
6 years ago
syntax = "proto3";
package envoy.admin.v2alpha;
option java_package = "io.envoyproxy.envoy.admin.v2alpha";
option java_outer_classname = "TapProto";
option java_multiple_files = true;
tap: introduce HTTP tap filter (#5515) This is a MVP for the HTTP tap filter. It includes minimal infrastructure for the following: 1. Generic tap configuration which in the future will be used for static config, XDS config, etc. In this MVP the tap can be configured via a /tap admin endpoint. 2. Generic output configuration which in the future will be used for different output sinks such as files, gRPC API, etc. In this MVP the tap results are streamed back out the /tap admin endpoint. 3. Matching infrastructure. In this MVP only matching on request and response headers are implemented. Both logical AND and logical OR matches are possible. 4. In this MVP request/response body is not considered at all. 5. All docs are included and with all the caveats the filter is ready to use for the limited cases it supports (which are likely still to be useful). There is a lot of follow on work which I will do in subsequent PRs. This includes: 1. Merging the existing capture transport socket into this framework. 2. Implementing body support, both for matching on body contents as well as outputting body data. 3. Tap rate limiting so too many streams do not get tapped. 4. gRPC matching. Using reflection and loaded proto definitions, it will be possible to match on gRPC fields. 5. JSON matching. If the body parses as JSON, we can allow matching on JSON fields. Part of https://github.com/envoyproxy/envoy/issues/1413. Signed-off-by: Matt Klein <mklein@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ cf80045587240d494e54e9772949bc9af5eda61f
6 years ago
import "envoy/service/tap/v2alpha/common.proto";
import "validate/validate.proto";
tap: introduce HTTP tap filter (#5515) This is a MVP for the HTTP tap filter. It includes minimal infrastructure for the following: 1. Generic tap configuration which in the future will be used for static config, XDS config, etc. In this MVP the tap can be configured via a /tap admin endpoint. 2. Generic output configuration which in the future will be used for different output sinks such as files, gRPC API, etc. In this MVP the tap results are streamed back out the /tap admin endpoint. 3. Matching infrastructure. In this MVP only matching on request and response headers are implemented. Both logical AND and logical OR matches are possible. 4. In this MVP request/response body is not considered at all. 5. All docs are included and with all the caveats the filter is ready to use for the limited cases it supports (which are likely still to be useful). There is a lot of follow on work which I will do in subsequent PRs. This includes: 1. Merging the existing capture transport socket into this framework. 2. Implementing body support, both for matching on body contents as well as outputting body data. 3. Tap rate limiting so too many streams do not get tapped. 4. gRPC matching. Using reflection and loaded proto definitions, it will be possible to match on gRPC fields. 5. JSON matching. If the body parses as JSON, we can allow matching on JSON fields. Part of https://github.com/envoyproxy/envoy/issues/1413. Signed-off-by: Matt Klein <mklein@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ cf80045587240d494e54e9772949bc9af5eda61f
6 years ago
// The /tap admin request body that is used to configure an active tap session.
message TapRequest {
// The opaque configuration ID used to match the configuration to a loaded extension.
// A tap extension configures a similar opaque ID that is used to match.
string config_id = 1 [(validate.rules).string = {min_bytes: 1}];
tap: introduce HTTP tap filter (#5515) This is a MVP for the HTTP tap filter. It includes minimal infrastructure for the following: 1. Generic tap configuration which in the future will be used for static config, XDS config, etc. In this MVP the tap can be configured via a /tap admin endpoint. 2. Generic output configuration which in the future will be used for different output sinks such as files, gRPC API, etc. In this MVP the tap results are streamed back out the /tap admin endpoint. 3. Matching infrastructure. In this MVP only matching on request and response headers are implemented. Both logical AND and logical OR matches are possible. 4. In this MVP request/response body is not considered at all. 5. All docs are included and with all the caveats the filter is ready to use for the limited cases it supports (which are likely still to be useful). There is a lot of follow on work which I will do in subsequent PRs. This includes: 1. Merging the existing capture transport socket into this framework. 2. Implementing body support, both for matching on body contents as well as outputting body data. 3. Tap rate limiting so too many streams do not get tapped. 4. gRPC matching. Using reflection and loaded proto definitions, it will be possible to match on gRPC fields. 5. JSON matching. If the body parses as JSON, we can allow matching on JSON fields. Part of https://github.com/envoyproxy/envoy/issues/1413. Signed-off-by: Matt Klein <mklein@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ cf80045587240d494e54e9772949bc9af5eda61f
6 years ago
// The tap configuration to load.
service.tap.v2alpha.TapConfig tap_config = 2 [(validate.rules).message = {required: true}];
tap: introduce HTTP tap filter (#5515) This is a MVP for the HTTP tap filter. It includes minimal infrastructure for the following: 1. Generic tap configuration which in the future will be used for static config, XDS config, etc. In this MVP the tap can be configured via a /tap admin endpoint. 2. Generic output configuration which in the future will be used for different output sinks such as files, gRPC API, etc. In this MVP the tap results are streamed back out the /tap admin endpoint. 3. Matching infrastructure. In this MVP only matching on request and response headers are implemented. Both logical AND and logical OR matches are possible. 4. In this MVP request/response body is not considered at all. 5. All docs are included and with all the caveats the filter is ready to use for the limited cases it supports (which are likely still to be useful). There is a lot of follow on work which I will do in subsequent PRs. This includes: 1. Merging the existing capture transport socket into this framework. 2. Implementing body support, both for matching on body contents as well as outputting body data. 3. Tap rate limiting so too many streams do not get tapped. 4. gRPC matching. Using reflection and loaded proto definitions, it will be possible to match on gRPC fields. 5. JSON matching. If the body parses as JSON, we can allow matching on JSON fields. Part of https://github.com/envoyproxy/envoy/issues/1413. Signed-off-by: Matt Klein <mklein@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ cf80045587240d494e54e9772949bc9af5eda61f
6 years ago
}