pub struct HttpRouteRule {
    pub matches: Option<Vec<HttpRouteMatch>>,
    pub filters: Option<Vec<HttpRouteFilter>>,
    pub backend_refs: Option<Vec<HttpBackendRef>>,
}
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 header version: 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 rules based on the following criteria, continuing on ties. Precedence must be given to the the Rule with the largest number of:

  • Characters in a matching non-wildcard hostname.
  • Characters in a matching hostname.
  • Characters in a matching path.
  • Header matches.
  • Query param matches.

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 the Route that has been given precedence, matching precedence MUST be granted to the first matching rule 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 a core filter multiple times has unspecified or custom conformance.

Support: Core

backend_refs: Option<Vec<HttpBackendRef>>

BackendRefs defines the backend(s) where matching requests should be sent.

A 500 status code MUST be returned if there are no BackendRefs or filters specified that would result in a response being sent.

A BackendRef is considered invalid when it refers to:

  • an unknown or unsupported kind of resource
  • a resource that does not exist
  • a resource in another namespace when the reference has not been explicitly allowed by a ReferencePolicy (or equivalent concept).

When a BackendRef 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.

When a BackendRef refers to a Service that has no ready endpoints, it is recommended to return a 503 status code.

Support: Core for Kubernetes Service Support: Custom for any other resource

Support for weight: Core

Trait Implementations

Returns a copy of the value. Read more

Performs copy-assignment from source. Read more

Formats the value using the given formatter. Read more

Deserialize this value from the given Serde deserializer. Read more

The name of the generated JSON Schema. Read more

Generates a JSON Schema for this type. Read more

Whether JSON Schemas generated for this type should be re-used where possible using the $ref keyword. Read more

This method tests for self and other values to be equal, and is used by ==. Read more

This method tests for !=.

Serialize this value into the given Serde serializer. Read more

Auto Trait Implementations

Blanket Implementations

Gets the TypeId of self. Read more

Immutably borrows from an owned value. Read more

Mutably borrows from an owned value. Read more

Returns the argument unchanged.

Calls U::from(self).

That is, this conversion is whatever the implementation of From<T> for U chooses to do.

The resulting type after obtaining ownership.

Creates owned data from borrowed data, usually by cloning. Read more

Uses borrowed data to replace owned data, usually by cloning. Read more

The type returned in the event of a conversion error.

Performs the conversion.

The type returned in the event of a conversion error.

Performs the conversion.