Struct gateway_api::experimental::tlsroutes::TLSRouteSpec

pub struct TLSRouteSpec {
    pub hostnames: Option<Vec<String>>,
    pub parent_refs: Option<Vec<TLSRouteParentRefs>>,
    pub rules: Vec<TLSRouteRules>,
}

Spec defines the desired state of TLSRoute.

Fields

hostnames: Option<Vec<String>>

Hostnames defines a set of SNI names that should match against the SNI attribute of TLS ClientHello message in TLS handshake. This matches the RFC 1123 definition of a hostname with 2 notable exceptions:

1. IPs are not allowed in SNI names per RFC 6066. 2. A hostname may be prefixed with a wildcard label (*.). The wildcard label must appear by itself as the first label. If a hostname is specified by both the Listener and TLSRoute, there must be at least one intersecting hostname for the TLSRoute to be attached to the Listener. For example:

• A Listener with test.example.com as the hostname matches TLSRoutes that have either not specified any hostnames, or have specified at least one of test.example.com or *.example.com. * A Listener with *.example.com as the hostname matches TLSRoutes that have either not specified any hostnames or have specified at least one hostname that matches the Listener hostname. For example, test.example.com and *.example.com would both match. On the other hand, example.com and test.example.net would not match. If both the Listener and TLSRoute have specified hostnames, any TLSRoute hostnames that do not match the Listener hostname MUST be ignored. For example, if a Listener specified *.example.com, and the TLSRoute specified test.example.com and test.example.net, test.example.net must not be considered for a match. If both the Listener and TLSRoute have specified hostnames, and none match with the criteria above, then the TLSRoute is not accepted. The implementation must raise an ‘Accepted’ Condition with a status of False in the corresponding RouteParentStatus. Support: Core

parent_refs: Option<Vec<TLSRouteParentRefs>>

ParentRefs references the resources (usually Gateways) that a Route wants to be attached to. Note that the referenced parent resource needs to allow this for the attachment to be complete. For Gateways, that means the Gateway needs to allow attachment from Routes of this kind and namespace. The only kind of parent resource with “Core” support is Gateway. This API may be extended in the future to support additional kinds of parent resources such as one of the route kinds. It is invalid to reference an identical parent more than once. It is valid to reference multiple distinct sections within the same parent resource, such as 2 Listeners within a Gateway. It is possible to separately reference multiple distinct objects that may be collapsed by an implementation. For example, some implementations may choose to merge compatible Gateway Listeners together. If that is the case, the list of routes attached to those resources should also be merged.

rules: Vec<TLSRouteRules>

Rules are a list of TLS matchers and actions.

Trait Implementations

impl Clone for TLSRouteSpec

fn clone(&self) -> TLSRouteSpec

Returns a copy of the value.

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

Performs copy-assignment from source.

impl Debug for TLSRouteSpec

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

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for TLSRouteSpec

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

Deserialize this value from the given Serde deserializer.

impl JsonSchema for TLSRouteSpec

fn schema_name() -> String

The name of the generated JSON Schema.

fn json_schema(gen: &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 Serialize for TLSRouteSpec

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

Serialize this value into the given Serde serializer.