Uses of Package
io.envoyproxy.envoy.api.v2.route
Packages that use io.envoyproxy.envoy.api.v2.route
Package
Description
-
Classes in io.envoyproxy.envoy.api.v2.route used by io.envoyproxy.envoy.api.v2ClassDescriptionThe top level element in the routing configuration is a virtual host.The top level element in the routing configuration is a virtual host.
-
Classes in io.envoyproxy.envoy.api.v2.route used by io.envoyproxy.envoy.api.v2.routeClassDescription[#next-free-field: 12][#next-free-field: 12]Protobuf type
envoy.api.v2.route.DecoratorProtobuf typeenvoy.api.v2.route.DecoratorProtobuf typeenvoy.api.v2.route.DirectResponseActionProtobuf typeenvoy.api.v2.route.DirectResponseActionA filter-defined action type.A filter-defined action type... attention:: Internally, Envoy always uses the HTTP/2 *:authority* header to represent the HTTP/1 *Host* header... attention:: Internally, Envoy always uses the HTTP/2 *:authority* header to represent the HTTP/1 *Host* header.HTTP request hedging :ref:`architecture overview <arch_overview_http_routing_hedging>`.HTTP request hedging :ref:`architecture overview <arch_overview_http_routing_hedging>`.Query parameter matching treats the query string of a request's :path header as an ampersand-separated list of keys and/or key=value elements.Query parameter matching treats the query string of a request's :path header as an ampersand-separated list of keys and/or key=value elements.Global rate limiting :ref:`architecture overview <arch_overview_global_rate_limit>`.[#next-free-field: 7][#next-free-field: 7]The following descriptor entry is appended to the descriptor: .. code-block:: cpp ("destination_cluster", "<routed target cluster>") Once a request matches against a route table rule, a routed cluster is determined by one of the following :ref:`route table configuration <envoy_api_msg_RouteConfiguration>` settings: * :ref:`cluster <envoy_api_field_route.RouteAction.cluster>` indicates the upstream cluster to route toThe following descriptor entry is appended to the descriptor: .. code-block:: cpp ("destination_cluster", "<routed target cluster>") Once a request matches against a route table rule, a routed cluster is determined by one of the following :ref:`route table configuration <envoy_api_msg_RouteConfiguration>` settings: * :ref:`cluster <envoy_api_field_route.RouteAction.cluster>` indicates the upstream cluster to route toThe following descriptor entry is appended to the descriptor: .. code-block:: cpp ("generic_key", "<descriptor_value>")The following descriptor entry is appended to the descriptor: .. code-block:: cpp ("generic_key", "<descriptor_value>")The following descriptor entry is appended to the descriptor: .. code-block:: cpp ("header_match", "<descriptor_value>")The following descriptor entry is appended to the descriptor: .. code-block:: cpp ("header_match", "<descriptor_value>")The following descriptor entry is appended to the descriptor and is populated using the trusted address from :ref:`x-forwarded-for <config_http_conn_man_headers_x-forwarded-for>`: .. code-block:: cpp ("remote_address", "<trusted address from x-forwarded-for>")The following descriptor entry is appended to the descriptor and is populated using the trusted address from :ref:`x-forwarded-for <config_http_conn_man_headers_x-forwarded-for>`: .. code-block:: cpp ("remote_address", "<trusted address from x-forwarded-for>")The following descriptor entry is appended when a header contains a key that matches the *header_name*: .. code-block:: cpp ("<descriptor_key>", "<header_value_queried_from_header>")The following descriptor entry is appended when a header contains a key that matches the *header_name*: .. code-block:: cpp ("<descriptor_key>", "<header_value_queried_from_header>")The following descriptor entry is appended to the descriptor: .. code-block:: cpp ("source_cluster", "<local service cluster>") <local service cluster> is derived from the :option:`--service-cluster` option.The following descriptor entry is appended to the descriptor: .. code-block:: cpp ("source_cluster", "<local service cluster>") <local service cluster> is derived from the :option:`--service-cluster` option.Global rate limiting :ref:`architecture overview <arch_overview_global_rate_limit>`.[#next-free-field: 9][#next-free-field: 9]Protobuf enumenvoy.api.v2.route.RedirectAction.RedirectResponseCodeHTTP retry :ref:`architecture overview <arch_overview_http_routing_retry>`.HTTP retry :ref:`architecture overview <arch_overview_http_routing_retry>`.Protobuf typeenvoy.api.v2.route.RetryPolicy.RetryBackOffProtobuf typeenvoy.api.v2.route.RetryPolicy.RetryBackOffProtobuf typeenvoy.api.v2.route.RetryPolicy.RetryHostPredicateProtobuf typeenvoy.api.v2.route.RetryPolicy.RetryHostPredicateProtobuf typeenvoy.api.v2.route.RetryPolicy.RetryPriorityProtobuf typeenvoy.api.v2.route.RetryPolicy.RetryPriorityA route is both a specification of how to match a request as well as an indication of what to do next (e.g., redirect, forward, rewrite, etc.). .. attention:: Envoy supports routing on HTTP method via :ref:`header matching <envoy_api_msg_route.HeaderMatcher>`.A route is both a specification of how to match a request as well as an indication of what to do next (e.g., redirect, forward, rewrite, etc.). .. attention:: Envoy supports routing on HTTP method via :ref:`header matching <envoy_api_msg_route.HeaderMatcher>`.[#next-free-field: 34][#next-free-field: 34]Protobuf enumenvoy.api.v2.route.RouteAction.ClusterNotFoundResponseCodeSpecifies the route's hashing policy if the upstream cluster uses a hashing :ref:`load balancer <arch_overview_load_balancing_types>`.Specifies the route's hashing policy if the upstream cluster uses a hashing :ref:`load balancer <arch_overview_load_balancing_types>`.Protobuf typeenvoy.api.v2.route.RouteAction.HashPolicy.ConnectionPropertiesProtobuf typeenvoy.api.v2.route.RouteAction.HashPolicy.ConnectionPropertiesEnvoy supports two types of cookie affinity: 1.Envoy supports two types of cookie affinity: 1.Protobuf typeenvoy.api.v2.route.RouteAction.HashPolicy.FilterStateProtobuf typeenvoy.api.v2.route.RouteAction.HashPolicy.FilterStateProtobuf typeenvoy.api.v2.route.RouteAction.HashPolicy.HeaderProtobuf typeenvoy.api.v2.route.RouteAction.HashPolicy.HeaderProtobuf typeenvoy.api.v2.route.RouteAction.HashPolicy.QueryParameterProtobuf typeenvoy.api.v2.route.RouteAction.HashPolicy.QueryParameterConfigures :ref:`internal redirect <arch_overview_internal_redirects>` behavior.The router is capable of shadowing traffic from one cluster to another.The router is capable of shadowing traffic from one cluster to another.Allows enabling and disabling upgrades on a per-route basis.Allows enabling and disabling upgrades on a per-route basis.[#next-free-field: 12][#next-free-field: 12]Protobuf typeenvoy.api.v2.route.RouteMatch.GrpcRouteMatchOptionsProtobuf typeenvoy.api.v2.route.RouteMatch.GrpcRouteMatchOptionsProtobuf typeenvoy.api.v2.route.RouteMatch.TlsContextMatchOptionsProtobuf typeenvoy.api.v2.route.RouteMatch.TlsContextMatchOptionsProtobuf typeenvoy.api.v2.route.TracingProtobuf typeenvoy.api.v2.route.TracingA virtual cluster is a way of specifying a regex matching rule against certain important endpoints such that statistics are generated explicitly for the matched requests.A virtual cluster is a way of specifying a regex matching rule against certain important endpoints such that statistics are generated explicitly for the matched requests.The top level element in the routing configuration is a virtual host.The top level element in the routing configuration is a virtual host.Protobuf enumenvoy.api.v2.route.VirtualHost.TlsRequirementTypeCompared to the :ref:`cluster <envoy_api_field_route.RouteAction.cluster>` field that specifies a single upstream cluster as the target of a request, the :ref:`weighted_clusters <envoy_api_field_route.RouteAction.weighted_clusters>` option allows for specification of multiple upstream clusters along with weights that indicate the percentage of traffic to be forwarded to each cluster.Compared to the :ref:`cluster <envoy_api_field_route.RouteAction.cluster>` field that specifies a single upstream cluster as the target of a request, the :ref:`weighted_clusters <envoy_api_field_route.RouteAction.weighted_clusters>` option allows for specification of multiple upstream clusters along with weights that indicate the percentage of traffic to be forwarded to each cluster.[#next-free-field: 11][#next-free-field: 11] -
Classes in io.envoyproxy.envoy.api.v2.route used by io.envoyproxy.envoy.config.filter.accesslog.v2ClassDescription.. attention:: Internally, Envoy always uses the HTTP/2 *:authority* header to represent the HTTP/1 *Host* header... attention:: Internally, Envoy always uses the HTTP/2 *:authority* header to represent the HTTP/1 *Host* header.
-
Classes in io.envoyproxy.envoy.api.v2.route used by io.envoyproxy.envoy.config.filter.http.cache.v2alphaClassDescriptionQuery parameter matching treats the query string of a request's :path header as an ampersand-separated list of keys and/or key=value elements.Query parameter matching treats the query string of a request's :path header as an ampersand-separated list of keys and/or key=value elements.
-
Classes in io.envoyproxy.envoy.api.v2.route used by io.envoyproxy.envoy.config.filter.http.fault.v2ClassDescription.. attention:: Internally, Envoy always uses the HTTP/2 *:authority* header to represent the HTTP/1 *Host* header... attention:: Internally, Envoy always uses the HTTP/2 *:authority* header to represent the HTTP/1 *Host* header.
-
Classes in io.envoyproxy.envoy.api.v2.route used by io.envoyproxy.envoy.config.filter.http.health_check.v2ClassDescription.. attention:: Internally, Envoy always uses the HTTP/2 *:authority* header to represent the HTTP/1 *Host* header... attention:: Internally, Envoy always uses the HTTP/2 *:authority* header to represent the HTTP/1 *Host* header.
-
Classes in io.envoyproxy.envoy.api.v2.route used by io.envoyproxy.envoy.config.filter.http.jwt_authn.v2alphaClassDescription[#next-free-field: 12][#next-free-field: 12]
-
Classes in io.envoyproxy.envoy.api.v2.route used by io.envoyproxy.envoy.config.filter.network.dubbo_proxy.v2alpha1ClassDescription.. attention:: Internally, Envoy always uses the HTTP/2 *:authority* header to represent the HTTP/1 *Host* header... attention:: Internally, Envoy always uses the HTTP/2 *:authority* header to represent the HTTP/1 *Host* header.Compared to the :ref:`cluster <envoy_api_field_route.RouteAction.cluster>` field that specifies a single upstream cluster as the target of a request, the :ref:`weighted_clusters <envoy_api_field_route.RouteAction.weighted_clusters>` option allows for specification of multiple upstream clusters along with weights that indicate the percentage of traffic to be forwarded to each cluster.Compared to the :ref:`cluster <envoy_api_field_route.RouteAction.cluster>` field that specifies a single upstream cluster as the target of a request, the :ref:`weighted_clusters <envoy_api_field_route.RouteAction.weighted_clusters>` option allows for specification of multiple upstream clusters along with weights that indicate the percentage of traffic to be forwarded to each cluster.
-
Classes in io.envoyproxy.envoy.api.v2.route used by io.envoyproxy.envoy.config.filter.network.thrift_proxy.v2alpha1ClassDescription.. attention:: Internally, Envoy always uses the HTTP/2 *:authority* header to represent the HTTP/1 *Host* header... attention:: Internally, Envoy always uses the HTTP/2 *:authority* header to represent the HTTP/1 *Host* header.Global rate limiting :ref:`architecture overview <arch_overview_global_rate_limit>`.Global rate limiting :ref:`architecture overview <arch_overview_global_rate_limit>`.
-
Classes in io.envoyproxy.envoy.api.v2.route used by io.envoyproxy.envoy.config.rbac.v2ClassDescription.. attention:: Internally, Envoy always uses the HTTP/2 *:authority* header to represent the HTTP/1 *Host* header... attention:: Internally, Envoy always uses the HTTP/2 *:authority* header to represent the HTTP/1 *Host* header.
-
Classes in io.envoyproxy.envoy.api.v2.route used by io.envoyproxy.envoy.service.tap.v2alphaClassDescription.. attention:: Internally, Envoy always uses the HTTP/2 *:authority* header to represent the HTTP/1 *Host* header... attention:: Internally, Envoy always uses the HTTP/2 *:authority* header to represent the HTTP/1 *Host* header.