1syntax = "proto3";
2
3package envoy.config.route.v3;
4
5import "envoy/config/core/v3/base.proto";
6import "envoy/config/core/v3/config_source.proto";
7import "envoy/config/route/v3/route_components.proto";
8
9import "google/protobuf/wrappers.proto";
10
11import "udpa/annotations/status.proto";
12import "udpa/annotations/versioning.proto";
13import "validate/validate.proto";
14
15option java_package = "io.envoyproxy.envoy.config.route.v3";
16option java_outer_classname = "RouteProto";
17option java_multiple_files = true;
18option (udpa.annotations.file_status).package_version_status = ACTIVE;
19
20// [#protodoc-title: HTTP route configuration]
21// * Routing :ref:`architecture overview <arch_overview_http_routing>`
22// * HTTP :ref:`router filter <config_http_filters_router>`
23
24// [#next-free-field: 11]
25message RouteConfiguration {
26 option (udpa.annotations.versioning).previous_message_type = "envoy.api.v2.RouteConfiguration";
27
28 // The name of the route configuration. For example, it might match
29 // :ref:`route_config_name
30 // <envoy_api_field_extensions.filters.network.http_connection_manager.v3.Rds.route_config_name>` in
31 // :ref:`envoy_api_msg_extensions.filters.network.http_connection_manager.v3.Rds`.
32 string name = 1;
33
34 // An array of virtual hosts that make up the route table.
35 repeated VirtualHost virtual_hosts = 2;
36
37 // An array of virtual hosts will be dynamically loaded via the VHDS API.
38 // Both *virtual_hosts* and *vhds* fields will be used when present. *virtual_hosts* can be used
39 // for a base routing table or for infrequently changing virtual hosts. *vhds* is used for
40 // on-demand discovery of virtual hosts. The contents of these two fields will be merged to
41 // generate a routing table for a given RouteConfiguration, with *vhds* derived configuration
42 // taking precedence.
43 Vhds vhds = 9;
44
45 // Optionally specifies a list of HTTP headers that the connection manager
46 // will consider to be internal only. If they are found on external requests they will be cleaned
47 // prior to filter invocation. See :ref:`config_http_conn_man_headers_x-envoy-internal` for more
48 // information.
49 repeated string internal_only_headers = 3 [
50 (validate.rules).repeated = {items {string {well_known_regex: HTTP_HEADER_NAME strict: false}}}
51 ];
52
53 // Specifies a list of HTTP headers that should be added to each response that
54 // the connection manager encodes. Headers specified at this level are applied
55 // after headers from any enclosed :ref:`envoy_api_msg_config.route.v3.VirtualHost` or
56 // :ref:`envoy_api_msg_config.route.v3.RouteAction`. For more information, including details on
57 // header value syntax, see the documentation on :ref:`custom request headers
58 // <config_http_conn_man_headers_custom_request_headers>`.
59 repeated core.v3.HeaderValueOption response_headers_to_add = 4
60 [(validate.rules).repeated = {max_items: 1000}];
61
62 // Specifies a list of HTTP headers that should be removed from each response
63 // that the connection manager encodes.
64 repeated string response_headers_to_remove = 5 [
65 (validate.rules).repeated = {items {string {well_known_regex: HTTP_HEADER_NAME strict: false}}}
66 ];
67
68 // Specifies a list of HTTP headers that should be added to each request
69 // routed by the HTTP connection manager. Headers specified at this level are
70 // applied after headers from any enclosed :ref:`envoy_api_msg_config.route.v3.VirtualHost` or
71 // :ref:`envoy_api_msg_config.route.v3.RouteAction`. For more information, including details on
72 // header value syntax, see the documentation on :ref:`custom request headers
73 // <config_http_conn_man_headers_custom_request_headers>`.
74 repeated core.v3.HeaderValueOption request_headers_to_add = 6
75 [(validate.rules).repeated = {max_items: 1000}];
76
77 // Specifies a list of HTTP headers that should be removed from each request
78 // routed by the HTTP connection manager.
79 repeated string request_headers_to_remove = 8 [
80 (validate.rules).repeated = {items {string {well_known_regex: HTTP_HEADER_NAME strict: false}}}
81 ];
82
83 // By default, headers that should be added/removed are evaluated from most to least specific:
84 //
85 // * route level
86 // * virtual host level
87 // * connection manager level
88 //
89 // To allow setting overrides at the route or virtual host level, this order can be reversed
90 // by setting this option to true. Defaults to false.
91 //
92 // [#next-major-version: In the v3 API, this will default to true.]
93 bool most_specific_header_mutations_wins = 10;
94
95 // An optional boolean that specifies whether the clusters that the route
96 // table refers to will be validated by the cluster manager. If set to true
97 // and a route refers to a non-existent cluster, the route table will not
98 // load. If set to false and a route refers to a non-existent cluster, the
99 // route table will load and the router filter will return a 404 if the route
100 // is selected at runtime. This setting defaults to true if the route table
101 // is statically defined via the :ref:`route_config
102 // <envoy_api_field_extensions.filters.network.http_connection_manager.v3.HttpConnectionManager.route_config>`
103 // option. This setting default to false if the route table is loaded dynamically via the
104 // :ref:`rds
105 // <envoy_api_field_extensions.filters.network.http_connection_manager.v3.HttpConnectionManager.rds>`
106 // option. Users may wish to override the default behavior in certain cases (for example when
107 // using CDS with a static route table).
108 google.protobuf.BoolValue validate_clusters = 7;
109}
110
111message Vhds {
112 option (udpa.annotations.versioning).previous_message_type = "envoy.api.v2.Vhds";
113
114 // Configuration source specifier for VHDS.
115 core.v3.ConfigSource config_source = 1 [(validate.rules).message = {required: true}];
116}
View as plain text