Auto-generated derived type for HTTPRouteSpec via CustomResource
ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually a route). There are two kinds of parent resources with “Core” support:
HTTPRouteRule defines semantics for matching an HTTP request based on conditions (matches), processing it (filters), and forwarding the request to an API object (backendRefs).
HTTPBackendRef defines how a HTTPRoute forwards a HTTP request.
Note that when a namespace different than the local namespace is specified, a ReferenceGrant object is required in the referent namespace to allow that namespace’s owner to accept the reference. See the ReferenceGrant documentation for details.
gateway:experimental:description
When the BackendRef points to a Kubernetes Service, implementations SHOULD honor the appProtocol field if it is set for the target Service Port.
Implementations supporting appProtocol SHOULD recognize the Kubernetes Standard Application Protocols defined in KEP-3726.
If a Service appProtocol isn’t specified, an implementation MAY infer the backend protocol through its own means. Implementations MAY infer the protocol from the Route type referring to the backend Service.
If a Route is not able to send traffic to the backend using the specified protocol then the backend is considered invalid. Implementations MUST set the “ResolvedRefs” condition to “False” with the “UnsupportedProtocol” reason.
</gateway:experimental:description>
HTTPRouteFilter defines processing steps that must be completed during the request or response lifecycle. HTTPRouteFilters are meant as an extension point to express processing that may be done in Gateway implementations. Some examples include request or response modification, implementing authentication strategies, rate-limiting, and traffic shaping. API guarantee/conformance is defined based on the type of the filter.
ExtensionRef is an optional, implementation-specific extension to the “filter” behavior. For example, resource “myroutefilter” in group “networking.example.net”). ExtensionRef MUST NOT be used for core and extended filters.
This filter can be used multiple times within the same rule.
Support: Implementation-specific
RequestHeaderModifier defines a schema for a filter that modifies request headers.
Support: Core
HTTPHeader represents an HTTP Header name and value as defined by RFC 7230.
HTTPHeader represents an HTTP Header name and value as defined by RFC 7230.
RequestMirror defines a schema for a filter that mirrors requests. Requests are sent to the specified destination, but responses from that destination are ignored.
This filter can be used multiple times within the same rule. Note that not all implementations will be able to support mirroring to multiple backends.
Support: Extended
BackendRef references a resource where mirrored requests are sent.
Mirrored requests must be sent only to a single destination endpoint within this BackendRef, irrespective of how many endpoints are present within this BackendRef.
If the referent cannot be found, this BackendRef is invalid and must be dropped from the Gateway. The controller must ensure the “ResolvedRefs” condition on the Route status is set to status: False and not configure this backend in the underlying implementation.
If there is a cross-namespace reference to an existing object that is not allowed by a ReferenceGrant, the controller must ensure the “ResolvedRefs” condition on the Route is set to status: False, with the “RefNotPermitted” reason and not configure this backend in the underlying implementation.
In either error case, the Message of the ResolvedRefs Condition should be used to provide more detail about the problem.
Support: Extended for Kubernetes Service
Support: Implementation-specific for any other resource
RequestRedirect defines a schema for a filter that responds to the request with an HTTP redirection.
Support: Core
Path defines parameters used to modify the path of the incoming request. The modified path is then used to construct the Location header. When empty, the request path is used as-is.
Support: Extended
ResponseHeaderModifier defines a schema for a filter that modifies response headers.
Support: Extended
HTTPHeader represents an HTTP Header name and value as defined by RFC 7230.
HTTPHeader represents an HTTP Header name and value as defined by RFC 7230.
URLRewrite defines a schema for a filter that modifies a request during forwarding.
Support: Extended
Path defines a path rewrite.
Support: Extended
HTTPRouteFilter defines processing steps that must be completed during the request or response lifecycle. HTTPRouteFilters are meant as an extension point to express processing that may be done in Gateway implementations. Some examples include request or response modification, implementing authentication strategies, rate-limiting, and traffic shaping. API guarantee/conformance is defined based on the type of the filter.
ExtensionRef is an optional, implementation-specific extension to the “filter” behavior. For example, resource “myroutefilter” in group “networking.example.net”). ExtensionRef MUST NOT be used for core and extended filters.
This filter can be used multiple times within the same rule.
Support: Implementation-specific
RequestHeaderModifier defines a schema for a filter that modifies request headers.
Support: Core
HTTPHeader represents an HTTP Header name and value as defined by RFC 7230.
HTTPHeader represents an HTTP Header name and value as defined by RFC 7230.
RequestMirror defines a schema for a filter that mirrors requests. Requests are sent to the specified destination, but responses from that destination are ignored.
This filter can be used multiple times within the same rule. Note that not all implementations will be able to support mirroring to multiple backends.
Support: Extended
BackendRef references a resource where mirrored requests are sent.
Mirrored requests must be sent only to a single destination endpoint within this BackendRef, irrespective of how many endpoints are present within this BackendRef.
If the referent cannot be found, this BackendRef is invalid and must be dropped from the Gateway. The controller must ensure the “ResolvedRefs” condition on the Route status is set to status: False and not configure this backend in the underlying implementation.
If there is a cross-namespace reference to an existing object that is not allowed by a ReferenceGrant, the controller must ensure the “ResolvedRefs” condition on the Route is set to status: False, with the “RefNotPermitted” reason and not configure this backend in the underlying implementation.
In either error case, the Message of the ResolvedRefs Condition should be used to provide more detail about the problem.
Support: Extended for Kubernetes Service
Support: Implementation-specific for any other resource
RequestRedirect defines a schema for a filter that responds to the request with an HTTP redirection.
Support: Core
Path defines parameters used to modify the path of the incoming request. The modified path is then used to construct the Location header. When empty, the request path is used as-is.
Support: Extended
ResponseHeaderModifier defines a schema for a filter that modifies response headers.
Support: Extended
HTTPHeader represents an HTTP Header name and value as defined by RFC 7230.
HTTPHeader represents an HTTP Header name and value as defined by RFC 7230.
URLRewrite defines a schema for a filter that modifies a request during forwarding.
Support: Extended
Path defines a path rewrite.
Support: Extended
HTTPRouteMatch defines the predicate used to match requests to a given action. Multiple match types are ANDed together, i.e. the match will evaluate to true only if all conditions are satisfied.
For example, the match below will match a HTTP request only if its path starts with /foo AND it contains the version: v1 header:
HTTPHeaderMatch describes how to select a HTTP route by matching HTTP request headers.
Path specifies a HTTP request path matcher. If this field is not specified, a default prefix match on the “/” path is provided.
HTTPQueryParamMatch describes how to select a HTTP route by matching HTTP query parameters.
Timeouts defines the timeouts that can be configured for an HTTP request.
Support: Extended
Spec defines the desired state of HTTPRoute.
Status defines the current state of HTTPRoute.
RouteParentStatus describes the status of a route with respect to an associated Parent.
Condition contains details for one aspect of the current state of this API Resource. — This struct is intended for direct use as an array at the field path .status.conditions. For example,
type FooStatus struct{ // Represents the observations of a foo’s current state. // Known .status.conditions.type are: “Available”, “Progressing”, and “Degraded” // +patchMergeKey=type // +patchStrategy=merge // +listType=map // +listMapKey=type Conditions []metav1.Condition json:"conditions,omitempty" patchStrategy:"merge" patchMergeKey:"type" protobuf:"bytes,1,rep,name=conditions"
// other fields }
ParentRef corresponds with a ParentRef in the spec that this RouteParentStatus struct describes the status of.
Path defines parameters used to modify the path of the incoming request. The modified path is then used to construct the Location header. When empty, the request path is used as-is.
Support: Extended
RequestRedirect defines a schema for a filter that responds to the request with an HTTP redirection.
Support: Core
RequestRedirect defines a schema for a filter that responds to the request with an HTTP redirection.
Support: Core
HTTPRouteFilter defines processing steps that must be completed during the request or response lifecycle. HTTPRouteFilters are meant as an extension point to express processing that may be done in Gateway implementations. Some examples include request or response modification, implementing authentication strategies, rate-limiting, and traffic shaping. API guarantee/conformance is defined based on the type of the filter.
Path defines a path rewrite.
Support: Extended
Path defines parameters used to modify the path of the incoming request. The modified path is then used to construct the Location header. When empty, the request path is used as-is.
Support: Extended
RequestRedirect defines a schema for a filter that responds to the request with an HTTP redirection.
Support: Core
RequestRedirect defines a schema for a filter that responds to the request with an HTTP redirection.
Support: Core
HTTPRouteFilter defines processing steps that must be completed during the request or response lifecycle. HTTPRouteFilters are meant as an extension point to express processing that may be done in Gateway implementations. Some examples include request or response modification, implementing authentication strategies, rate-limiting, and traffic shaping. API guarantee/conformance is defined based on the type of the filter.
Path defines a path rewrite.
Support: Extended
HTTPHeaderMatch describes how to select a HTTP route by matching HTTP request headers.
HTTPRouteMatch defines the predicate used to match requests to a given action. Multiple match types are ANDed together, i.e. the match will evaluate to true only if all conditions are satisfied.
For example, the match below will match a HTTP request only if its path starts with /foo AND it contains the version: v1 header:
Path specifies a HTTP request path matcher. If this field is not specified, a default prefix match on the “/” path is provided.
HTTPQueryParamMatch describes how to select a HTTP route by matching HTTP query parameters.
Condition contains details for one aspect of the current state of this API Resource. — This struct is intended for direct use as an array at the field path .status.conditions. For example,
type FooStatus struct{ // Represents the observations of a foo’s current state. // Known .status.conditions.type are: “Available”, “Progressing”, and “Degraded” // +patchMergeKey=type // +patchStrategy=merge // +listType=map // +listMapKey=type Conditions []metav1.Condition json:"conditions,omitempty" patchStrategy:"merge" patchMergeKey:"type" protobuf:"bytes,1,rep,name=conditions"
// other fields }