Struct k8s_gateway_api::HttpRouteRule
source · pub struct HttpRouteRule {
pub matches: Option<Vec<HttpRouteMatch>>,
pub filters: Option<Vec<HttpRouteFilter>>,
pub backend_refs: Option<Vec<HttpBackendRef>>,
pub timeouts: Option<HttpRouteTimeouts>,
}
Expand description
HTTPRouteRule defines semantics for matching an HTTP request based on conditions (matches), processing it (filters), and forwarding the request to an API object (backendRefs).
Fields§
§matches: Option<Vec<HttpRouteMatch>>
Matches define conditions used for matching the rule against incoming HTTP requests. Each match is independent, i.e. this rule will be matched if any one of the matches is satisfied.
For example, take the following matches configuration:
matches:
- path:
value: "/foo"
headers:
- name: "version"
value: "v2"
- path:
value: "/v2/foo"
For a request to match against this rule, a request must satisfy EITHER of the two conditions:
- path prefixed with
/foo
AND contains the headerversion: v2
- path prefix of
/v2/foo
See the documentation for HTTPRouteMatch on how to specify multiple match conditions that should be ANDed together.
If no matches are specified, the default is a prefix path match on “/”, which has the effect of matching every HTTP request.
Proxy or Load Balancer routing configuration generated from HTTPRoutes MUST prioritize matches based on the following criteria, continuing on ties. Across all rules specified on applicable Routes, precedence must be given to the match having:
- “Exact” path match.
- “Prefix” path match with largest number of characters.
- Method match.
- Largest number of header matches.
- Largest number of query param matches.
Note: The precedence of RegularExpression path matches are implementation-specific.
If ties still exist across multiple Routes, matching precedence MUST be determined in order of the following criteria, continuing on ties:
- The oldest Route based on creation timestamp.
- The Route appearing first in alphabetical order by “{namespace}/{name}”.
If ties still exist within an HTTPRoute, matching precedence MUST be granted to the FIRST matching rule (in list order) with a match meeting the above criteria.
When no rules matching a request have been successfully attached to the parent a request is coming from, a HTTP 404 status code MUST be returned.
filters: Option<Vec<HttpRouteFilter>>
Filters define the filters that are applied to requests that match this rule.
The effects of ordering of multiple behaviors are currently unspecified. This can change in the future based on feedback during the alpha stage.
Conformance-levels at this level are defined based on the type of filter:
- ALL core filters MUST be supported by all implementations.
- Implementers are encouraged to support extended filters.
- Implementation-specific custom filters have no API guarantees across implementations.
Specifying the same filter multiple times is not supported unless explicitly indicated in the filter.
All filters are expected to be compatible with each other except for the
URLRewrite and RequestRedirect filters, which may not be combined. If an
implementation can not support other combinations of filters, they must clearly
document that limitation. In cases where incompatible or unsupported
filters are specified and cause the Accepted
condition to be set to status
False
, implementations may use the IncompatibleFilters
reason to specify
this configuration error.
Support: Core
backend_refs: Option<Vec<HttpBackendRef>>
BackendRefs defines the backend(s) where matching requests should be sent.
Failure behavior here depends on how many BackendRefs are specified and how many are invalid.
If all entries in BackendRefs are invalid, and there are also no filters specified in this route rule, all traffic which matches this rule MUST receive a 500 status code.
See the HTTPBackendRef definition for the rules about what makes a single HTTPBackendRef invalid.
When a HTTPBackendRef is invalid, 500 status codes MUST be returned for requests that would have otherwise been routed to an invalid backend. If multiple backends are specified, and some are invalid, the proportion of requests that would otherwise have been routed to an invalid backend MUST receive a 500 status code.
For example, if two backends are specified with equal weights, and one is invalid, 50 percent of traffic must receive a 500. Implementations may choose how that 50 percent is determined.
Support: Core for Kubernetes Service
Support: Extended for Kubernetes ServiceImport
Support: Implementation-specific for any other resource
Support for weight: Core
timeouts: Option<HttpRouteTimeouts>
Trait Implementations§
source§impl Clone for HttpRouteRule
impl Clone for HttpRouteRule
source§fn clone(&self) -> HttpRouteRule
fn clone(&self) -> HttpRouteRule
1.0.0 · source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source
. Read moresource§impl Debug for HttpRouteRule
impl Debug for HttpRouteRule
source§impl<'de> Deserialize<'de> for HttpRouteRule
impl<'de> Deserialize<'de> for HttpRouteRule
source§fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>where
__D: Deserializer<'de>,
fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>where
__D: Deserializer<'de>,
source§impl JsonSchema for HttpRouteRule
impl JsonSchema for HttpRouteRule
source§fn schema_name() -> String
fn schema_name() -> String
source§fn schema_id() -> Cow<'static, str>
fn schema_id() -> Cow<'static, str>
source§fn json_schema(gen: &mut SchemaGenerator) -> Schema
fn json_schema(gen: &mut SchemaGenerator) -> Schema
source§fn is_referenceable() -> bool
fn is_referenceable() -> bool
$ref
keyword. Read moresource§impl PartialEq for HttpRouteRule
impl PartialEq for HttpRouteRule
source§fn eq(&self, other: &HttpRouteRule) -> bool
fn eq(&self, other: &HttpRouteRule) -> bool
self
and other
values to be equal, and is used
by ==
.