Struct HttpRouteRule 

pub struct HttpRouteRule {
    pub matches: Option<Vec<HttpRouteMatch>>,
    pub filters: Option<Vec<HttpRouteFilter>>,
    pub backend_refs: Option<Vec<HttpBackendRef>>,
    pub timeout_ms: Option<u32>,
}

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

timeout_ms: Option<u32>

Trait Implementations

impl Clone for HttpRouteRule

fn clone(&self) -> HttpRouteRule

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for HttpRouteRule

fn fmt(&self, f: &mut Formatter<'_>) -> Result<(), Error>

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for HttpRouteRule

fn deserialize<__D>( __deserializer: __D, ) -> Result<HttpRouteRule, <__D as Deserializer<'de>>::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl JsonSchema for HttpRouteRule

fn schema_name() -> String

The name of the generated JSON Schema.

fn schema_id() -> Cow<'static, str>

Returns a string that uniquely identifies the schema produced by this type.

fn json_schema(generator: &mut SchemaGenerator) -> Schema

Generates a JSON Schema for this type.

fn is_referenceable() -> bool

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

impl PartialEq for HttpRouteRule

fn eq(&self, other: &HttpRouteRule) -> bool

Tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl Serialize for HttpRouteRule

fn serialize<__S>( &self, __serializer: __S, ) -> Result<<__S as Serializer>::Ok, <__S as Serializer>::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.

impl Eq for HttpRouteRule

impl StructuralPartialEq for HttpRouteRule