| Name | +Type | +Description | +Required | +
|---|---|---|---|
| metadata | +object | +
+ ObjectMeta contains only a [subset of the fields included in k8s.io/apimachinery/pkg/apis/meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.27/#objectmeta-v1-meta). + |
+ false | +
| spec | +object | +
+ HTTPRouteSpec defines the desired state of HTTPRoute + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| annotations | +map[string]string | +
+ + |
+ false | +
| labels | +map[string]string | +
+ + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| hostnames | +[]string | +
+ Hostnames defines a set of hostnames that should match against the HTTP Host
+header to select a HTTPRoute used to process the request. Implementations
+MUST ignore any port value specified in the HTTP Host header while
+performing a match and (absent of any applicable header modification
+configuration) MUST forward this header unmodified to the backend.
+
+Valid values for Hostnames are determined by RFC 1123 definition of a
+hostname with 2 notable exceptions:
+
+1. IPs are not allowed.
+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 HTTPRoute, there
+must be at least one intersecting hostname for the HTTPRoute to be
+attached to the Listener. For example:
+
+* A Listener with `test.example.com` as the hostname matches HTTPRoutes
+ 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 HTTPRoutes
+ that have either not specified any hostnames or have specified at least
+ one hostname that matches the Listener hostname. For example,
+ `*.example.com`, `test.example.com`, and `foo.test.example.com` would
+ all match. On the other hand, `example.com` and `test.example.net` would
+ not match.
+
+Hostnames that are prefixed with a wildcard label (`*.`) are interpreted
+as a suffix match. That means that a match for `*.example.com` would match
+both `test.example.com`, and `foo.test.example.com`, but not `example.com`.
+
+If both the Listener and HTTPRoute have specified hostnames, any
+HTTPRoute hostnames that do not match the Listener hostname MUST be
+ignored. For example, if a Listener specified `*.example.com`, and the
+HTTPRoute specified `test.example.com` and `test.example.net`,
+`test.example.net` must not be considered for a match.
+
+If both the Listener and HTTPRoute have specified hostnames, and none
+match with the criteria above, then the HTTPRoute is not accepted. The
+implementation must raise an 'Accepted' Condition with a status of
+`False` in the corresponding RouteParentStatus.
+
+In the event that multiple HTTPRoutes specify intersecting hostnames (e.g.
+overlapping wildcard matching and exact matching hostnames), precedence must
+be given to rules from the HTTPRoute with the largest number of:
+
+* Characters in a matching non-wildcard hostname.
+* Characters in a matching hostname.
+
+If ties exist across multiple Routes, the matching precedence rules for
+HTTPRouteMatches takes over.
+
+Support: Core + |
+ false | +
| parentRefs | +[]object | +
+ 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. For Services, that means the Service must either be in the same
+namespace for a "producer" route, or the mesh implementation must support
+and allow "consumer" routes for the referenced Service. ReferenceGrant is
+not applicable for governing ParentRefs to Services - it is not possible to
+create a "producer" route for a Service in a different namespace from the
+Route.
+
+There are two kinds of parent resources with "Core" support:
+
+* Gateway (Gateway conformance profile)
+* Service (Mesh conformance profile, ClusterIP Services only)
+
+This API may be extended in the future to support additional kinds of parent
+resources.
+
+ParentRefs must be _distinct_. This means either that:
+
+* They select different objects. If this is the case, then parentRef
+ entries are distinct. In terms of fields, this means that the
+ multi-part key defined by `group`, `kind`, `namespace`, and `name` must
+ be unique across all parentRef entries in the Route.
+* They do not select different objects, but for each optional field used,
+ each ParentRef that selects the same object must set the same set of
+ optional fields to different values. If one ParentRef sets a
+ combination of optional fields, all must set the same combination.
+
+Some examples:
+
+* If one ParentRef sets `sectionName`, all ParentRefs referencing the
+ same object must also set `sectionName`.
+* If one ParentRef sets `port`, all ParentRefs referencing the same
+ object must also set `port`.
+* If one ParentRef sets `sectionName` and `port`, all ParentRefs
+ referencing the same object must also set `sectionName` and `port`.
+
+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.
+
+Note that for ParentRefs that cross namespace boundaries, there are specific
+rules. Cross-namespace references are only valid if they are explicitly
+allowed by something in the namespace they are referring to. For example,
+Gateway has the AllowedRoutes field, and ReferenceGrant provides a
+generic way to enable other kinds of cross-namespace reference.
+
+ + |
+ false | +
| rules | +[]object | +
+ Rules are a list of HTTP matchers, filters and actions.
+
+ + + Validations: + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| name | +string | +
+ Name is the name of the referent.
+
+Support: Core + |
+ true | +
| group | +string | +
+ Group is the group of the referent.
+When unspecified, "gateway.networking.k8s.io" is inferred.
+To set the core API group (such as for a "Service" kind referent),
+Group must be explicitly set to "" (empty string).
+
+Support: Core + + Default: gateway.networking.k8s.io + |
+ false | +
| kind | +string | +
+ Kind is kind of the referent.
+
+There are two kinds of parent resources with "Core" support:
+
+* Gateway (Gateway conformance profile)
+* Service (Mesh conformance profile, ClusterIP Services only)
+
+Support for other resources is Implementation-Specific. + + Default: Gateway + |
+ false | +
| namespace | +string | +
+ Namespace is the namespace of the referent. When unspecified, this refers
+to the local namespace of the Route.
+
+Note that there are specific rules for ParentRefs which cross namespace
+boundaries. Cross-namespace references are only valid if they are explicitly
+allowed by something in the namespace they are referring to. For example:
+Gateway has the AllowedRoutes field, and ReferenceGrant provides a
+generic way to enable any other kind of cross-namespace reference.
+
+ + |
+ false | +
| port | +integer | +
+ Port is the network port this Route targets. It can be interpreted
+differently based on the type of parent resource.
+
+When the parent resource is a Gateway, this targets all listeners
+listening on the specified port that also support this kind of Route(and
+select this Route). It's not recommended to set `Port` unless the
+networking behaviors specified in a Route must apply to a specific port
+as opposed to a listener(s) whose port(s) may be changed. When both Port
+and SectionName are specified, the name and port of the selected listener
+must match both specified values.
+
+ + + Format: int32 + Minimum: 1 + Maximum: 65535 + |
+ false | +
| sectionName | +string | +
+ SectionName is the name of a section within the target resource. In the
+following resources, SectionName is interpreted as the following:
+
+* Gateway: Listener name. When both Port (experimental) and SectionName
+are specified, the name and port of the selected listener must match
+both specified values.
+* Service: Port name. When both Port (experimental) and SectionName
+are specified, the name and port of the selected listener must match
+both specified values.
+
+Implementations MAY choose to support attaching Routes to other resources.
+If that is the case, they MUST clearly document how SectionName is
+interpreted.
+
+When unspecified (empty string), this will reference the entire resource.
+For the purpose of status, an attachment is considered successful if at
+least one section in the parent resource accepts it. For example, Gateway
+listeners can restrict which Routes can attach to them by Route kind,
+namespace, or hostname. If 1 of 2 Gateway listeners accept attachment from
+the referencing Route, the Route MUST be considered successfully
+attached. If no Gateway listeners accept attachment from this Route, the
+Route MUST be considered detached from the Gateway.
+
+Support: Core + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| backendRefs | +[]object | +
+ 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.
+
+When a HTTPBackendRef refers to a Service that has no ready endpoints,
+implementations SHOULD return a 503 for requests to that backend instead.
+If an implementation chooses to do this, all of the above rules for 500 responses
+MUST also apply for responses that return a 503.
+
+Support: Core for Kubernetes Service
+
+Support: Extended for Kubernetes ServiceImport
+
+Support: Implementation-specific for any other resource
+
+Support for weight: Core + |
+ false | +
| filters | +[]object | +
+ Filters define the filters that are applied to requests that match
+this rule.
+
+Wherever possible, implementations SHOULD implement filters in the order
+they are specified.
+
+Implementations MAY choose to implement this ordering strictly, rejecting
+any combination or order of filters that cannot be supported. If implementations
+choose a strict interpretation of filter ordering, they MUST clearly document
+that behavior.
+
+To reject an invalid combination or order of filters, implementations SHOULD
+consider the Route Rules with this configuration invalid. If all Route Rules
+in a Route are invalid, the entire Route would be considered invalid. If only
+a portion of Route Rules are invalid, implementations MUST set the
+"PartiallyInvalid" condition for the Route.
+
+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 cannot 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 + + Validations: |
+ false | +
| matches | +[]object | +
+ 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 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. + + Default: [map[path:map[type:PathPrefix value:/]]] + |
+ false | +
| name | +string | +
+ Name is the name of the route rule. This name MUST be unique within a Route if it is set.
+
+Support: Extended
+ + |
+ false | +
| retry | +object | +
+ Retry defines the configuration for when to retry an HTTP request.
+
+Support: Extended
+
+ + |
+ false | +
| sessionPersistence | +object | +
+ SessionPersistence defines and configures session persistence
+for the route rule.
+
+Support: Extended
+
+ + + Validations: |
+ false | +
| timeouts | +object | +
+ Timeouts defines the timeouts that can be configured for an HTTP request.
+
+Support: Extended + + Validations: |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| name | +string | +
+ Name is the name of the referent. + |
+ true | +
| filters | +[]object | +
+ Filters defined at this level should be executed if and only if the
+request is being forwarded to the backend defined here.
+
+Support: Implementation-specific (For broader support of filters, use the
+Filters field in HTTPRouteRule.) + + Validations: |
+ false | +
| group | +string | +
+ Group is the group of the referent. For example, "gateway.networking.k8s.io".
+When unspecified or empty string, core API group is inferred. + + Default: + |
+ false | +
| kind | +string | +
+ Kind is the Kubernetes resource kind of the referent. For example
+"Service".
+
+Defaults to "Service" when not specified.
+
+ExternalName services can refer to CNAME DNS records that may live
+outside of the cluster and as such are difficult to reason about in
+terms of conformance. They also may not be safe to forward to (see
+CVE-2021-25740 for more information). Implementations SHOULD NOT
+support ExternalName Services.
+
+Support: Core (Services with a type other than ExternalName)
+
+Support: Implementation-specific (Services with type ExternalName) + + Default: Service + |
+ false | +
| namespace | +string | +
+ Namespace is the namespace of the backend. When unspecified, the local
+namespace is inferred.
+
+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.
+
+Support: Core + |
+ false | +
| port | +integer | +
+ Port specifies the destination port number to use for this resource.
+Port is required when the referent is a Kubernetes Service. In this
+case, the port number is the service port number, not the target port.
+For other resources, destination port might be derived from the referent
+resource or this field. + + Format: int32 + Minimum: 1 + Maximum: 65535 + |
+ false | +
| weight | +integer | +
+ Weight specifies the proportion of requests forwarded to the referenced
+backend. This is computed as weight/(sum of all weights in this
+BackendRefs list). For non-zero values, there may be some epsilon from
+the exact proportion defined here depending on the precision an
+implementation supports. Weight is not a percentage and the sum of
+weights does not need to equal 100.
+
+If only one backend is specified and it has a weight greater than 0, 100%
+of the traffic is forwarded to that backend. If weight is set to 0, no
+traffic should be forwarded for this entry. If unspecified, weight
+defaults to 1.
+
+Support for this field varies based on the context where used. + + Format: int32 + Default: 1 + Minimum: 0 + Maximum: 1e+06 + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| type | +enum | +
+ Type identifies the type of filter to apply. As with other API fields,
+types are classified into three conformance levels:
+
+- Core: Filter types and their corresponding configuration defined by
+ "Support: Core" in this package, e.g. "RequestHeaderModifier". All
+ implementations must support core filters.
+
+- Extended: Filter types and their corresponding configuration defined by
+ "Support: Extended" in this package, e.g. "RequestMirror". Implementers
+ are encouraged to support extended filters.
+
+- Implementation-specific: Filters that are defined and supported by
+ specific vendors.
+ In the future, filters showing convergence in behavior across multiple
+ implementations will be considered for inclusion in extended or core
+ conformance levels. Filter-specific configuration for such filters
+ is specified using the ExtensionRef field. `Type` should be set to
+ "ExtensionRef" for custom filters.
+
+Implementers are encouraged to define custom implementation types to
+extend the core API with implementation-specific behavior.
+
+If a reference to a custom filter type cannot be resolved, the filter
+MUST NOT be skipped. Instead, requests that would have been processed by
+that filter MUST receive a HTTP error response.
+
+Note that values may be added to this enum, implementations
+must ensure that unknown values will not cause a crash.
+
+Unknown values here must result in the implementation setting the
+Accepted Condition for the Route to `status: False`, with a
+Reason of `UnsupportedValue`.
+
+ + + Enum: RequestHeaderModifier, ResponseHeaderModifier, RequestMirror, RequestRedirect, URLRewrite, ExtensionRef + |
+ true | +
| cors | +object | +
+ CORS defines a schema for a filter that responds to the
+cross-origin request based on HTTP response header.
+
+Support: Extended
+
+ + |
+ false | +
| extensionRef | +object | +
+ 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 + |
+ false | +
| requestHeaderModifier | +object | +
+ RequestHeaderModifier defines a schema for a filter that modifies request
+headers.
+
+Support: Core + |
+ false | +
| requestMirror | +object | +
+ 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 + + Validations: |
+ false | +
| requestRedirect | +object | +
+ RequestRedirect defines a schema for a filter that responds to the
+request with an HTTP redirection.
+
+Support: Core + |
+ false | +
| responseHeaderModifier | +object | +
+ ResponseHeaderModifier defines a schema for a filter that modifies response
+headers.
+
+Support: Extended + |
+ false | +
| urlRewrite | +object | +
+ URLRewrite defines a schema for a filter that modifies a request during forwarding.
+
+Support: Extended + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| allowCredentials | +boolean | +
+ AllowCredentials indicates whether the actual cross-origin request allows
+to include credentials.
+
+The only valid value for the `Access-Control-Allow-Credentials` response
+header is true (case-sensitive).
+
+If the credentials are not allowed in cross-origin requests, the gateway
+will omit the header `Access-Control-Allow-Credentials` entirely rather
+than setting its value to false.
+
+Support: Extended + + Enum: true + |
+ false | +
| allowHeaders | +[]string | +
+ AllowHeaders indicates which HTTP request headers are supported for
+accessing the requested resource.
+
+Header names are not case sensitive.
+
+Multiple header names in the value of the `Access-Control-Allow-Headers`
+response header are separated by a comma (",").
+
+When the `AllowHeaders` field is configured with one or more headers, the
+gateway must return the `Access-Control-Allow-Headers` response header
+which value is present in the `AllowHeaders` field.
+
+If any header name in the `Access-Control-Request-Headers` request header
+is not included in the list of header names specified by the response
+header `Access-Control-Allow-Headers`, it will present an error on the
+client side.
+
+If any header name in the `Access-Control-Allow-Headers` response header
+does not recognize by the client, it will also occur an error on the
+client side.
+
+A wildcard indicates that the requests with all HTTP headers are allowed.
+The `Access-Control-Allow-Headers` response header can only use `*`
+wildcard as value when the `AllowCredentials` field is unspecified.
+
+When the `AllowCredentials` field is specified and `AllowHeaders` field
+specified with the `*` wildcard, the gateway must specify one or more
+HTTP headers in the value of the `Access-Control-Allow-Headers` response
+header. The value of the header `Access-Control-Allow-Headers` is same as
+the `Access-Control-Request-Headers` header provided by the client. If
+the header `Access-Control-Request-Headers` is not included in the
+request, the gateway will omit the `Access-Control-Allow-Headers`
+response header, instead of specifying the `*` wildcard. A Gateway
+implementation may choose to add implementation-specific default headers.
+
+Support: Extended + |
+ false | +
| allowMethods | +[]enum | +
+ AllowMethods indicates which HTTP methods are supported for accessing the
+requested resource.
+
+Valid values are any method defined by RFC9110, along with the special
+value `*`, which represents all HTTP methods are allowed.
+
+Method names are case sensitive, so these values are also case-sensitive.
+(See https://www.rfc-editor.org/rfc/rfc2616#section-5.1.1)
+
+Multiple method names in the value of the `Access-Control-Allow-Methods`
+response header are separated by a comma (",").
+
+A CORS-safelisted method is a method that is `GET`, `HEAD`, or `POST`.
+(See https://fetch.spec.whatwg.org/#cors-safelisted-method) The
+CORS-safelisted methods are always allowed, regardless of whether they
+are specified in the `AllowMethods` field.
+
+When the `AllowMethods` field is configured with one or more methods, the
+gateway must return the `Access-Control-Allow-Methods` response header
+which value is present in the `AllowMethods` field.
+
+If the HTTP method of the `Access-Control-Request-Method` request header
+is not included in the list of methods specified by the response header
+`Access-Control-Allow-Methods`, it will present an error on the client
+side.
+
+The `Access-Control-Allow-Methods` response header can only use `*`
+wildcard as value when the `AllowCredentials` field is unspecified.
+
+When the `AllowCredentials` field is specified and `AllowMethods` field
+specified with the `*` wildcard, the gateway must specify one HTTP method
+in the value of the Access-Control-Allow-Methods response header. The
+value of the header `Access-Control-Allow-Methods` is same as the
+`Access-Control-Request-Method` header provided by the client. If the
+header `Access-Control-Request-Method` is not included in the request,
+the gateway will omit the `Access-Control-Allow-Methods` response header,
+instead of specifying the `*` wildcard. A Gateway implementation may
+choose to add implementation-specific default methods.
+
+Support: Extended + + Validations: + |
+ false | +
| allowOrigins | +[]string | +
+ AllowOrigins indicates whether the response can be shared with requested
+resource from the given `Origin`.
+
+The `Origin` consists of a scheme and a host, with an optional port, and
+takes the form ` + |
+ false | +
| exposeHeaders | +[]string | +
+ ExposeHeaders indicates which HTTP response headers can be exposed
+to client-side scripts in response to a cross-origin request.
+
+A CORS-safelisted response header is an HTTP header in a CORS response
+that it is considered safe to expose to the client scripts.
+The CORS-safelisted response headers include the following headers:
+`Cache-Control`
+`Content-Language`
+`Content-Length`
+`Content-Type`
+`Expires`
+`Last-Modified`
+`Pragma`
+(See https://fetch.spec.whatwg.org/#cors-safelisted-response-header-name)
+The CORS-safelisted response headers are exposed to client by default.
+
+When an HTTP header name is specified using the `ExposeHeaders` field,
+this additional header will be exposed as part of the response to the
+client.
+
+Header names are not case sensitive.
+
+Multiple header names in the value of the `Access-Control-Expose-Headers`
+response header are separated by a comma (",").
+
+A wildcard indicates that the responses with all HTTP headers are exposed
+to clients. The `Access-Control-Expose-Headers` response header can only
+use `*` wildcard as value when the `AllowCredentials` field is
+unspecified.
+
+Support: Extended + |
+ false | +
| maxAge | +integer | +
+ MaxAge indicates the duration (in seconds) for the client to cache the
+results of a "preflight" request.
+
+The information provided by the `Access-Control-Allow-Methods` and
+`Access-Control-Allow-Headers` response headers can be cached by the
+client until the time specified by `Access-Control-Max-Age` elapses.
+
+The default value of `Access-Control-Max-Age` response header is 5
+(seconds). + + Format: int32 + Default: 5 + Minimum: 1 + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| group | +string | +
+ Group is the group of the referent. For example, "gateway.networking.k8s.io".
+When unspecified or empty string, core API group is inferred. + |
+ true | +
| kind | +string | +
+ Kind is kind of the referent. For example "HTTPRoute" or "Service". + |
+ true | +
| name | +string | +
+ Name is the name of the referent. + |
+ true | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| add | +[]object | +
+ Add adds the given header(s) (name, value) to the request
+before the action. It appends to any existing values associated
+with the header name.
+
+Input:
+ GET /foo HTTP/1.1
+ my-header: foo
+
+Config:
+ add:
+ - name: "my-header"
+ value: "bar,baz"
+
+Output:
+ GET /foo HTTP/1.1
+ my-header: foo,bar,baz + |
+ false | +
| remove | +[]string | +
+ Remove the given header(s) from the HTTP request before the action. The
+value of Remove is a list of HTTP header names. Note that the header
+names are case-insensitive (see
+https://datatracker.ietf.org/doc/html/rfc2616#section-4.2).
+
+Input:
+ GET /foo HTTP/1.1
+ my-header1: foo
+ my-header2: bar
+ my-header3: baz
+
+Config:
+ remove: ["my-header1", "my-header3"]
+
+Output:
+ GET /foo HTTP/1.1
+ my-header2: bar + |
+ false | +
| set | +[]object | +
+ Set overwrites the request with the given header (name, value)
+before the action.
+
+Input:
+ GET /foo HTTP/1.1
+ my-header: foo
+
+Config:
+ set:
+ - name: "my-header"
+ value: "bar"
+
+Output:
+ GET /foo HTTP/1.1
+ my-header: bar + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| name | +string | +
+ Name is the name of the HTTP Header to be matched. Name matching MUST be
+case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2).
+
+If multiple entries specify equivalent header names, the first entry with
+an equivalent name MUST be considered for a match. Subsequent entries
+with an equivalent header name MUST be ignored. Due to the
+case-insensitivity of header names, "foo" and "Foo" are considered
+equivalent. + |
+ true | +
| value | +string | +
+ Value is the value of HTTP Header to be matched. + |
+ true | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| name | +string | +
+ Name is the name of the HTTP Header to be matched. Name matching MUST be
+case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2).
+
+If multiple entries specify equivalent header names, the first entry with
+an equivalent name MUST be considered for a match. Subsequent entries
+with an equivalent header name MUST be ignored. Due to the
+case-insensitivity of header names, "foo" and "Foo" are considered
+equivalent. + |
+ true | +
| value | +string | +
+ Value is the value of HTTP Header to be matched. + |
+ true | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| backendRef | +object | +
+ 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 + + Validations: |
+ true | +
| fraction | +object | +
+ Fraction represents the fraction of requests that should be
+mirrored to BackendRef.
+
+Only one of Fraction or Percent may be specified. If neither field
+is specified, 100% of requests will be mirrored. + + Validations: |
+ false | +
| percent | +integer | +
+ Percent represents the percentage of requests that should be
+mirrored to BackendRef. Its minimum value is 0 (indicating 0% of
+requests) and its maximum value is 100 (indicating 100% of requests).
+
+Only one of Fraction or Percent may be specified. If neither field
+is specified, 100% of requests will be mirrored. + + Format: int32 + Minimum: 0 + Maximum: 100 + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| name | +string | +
+ Name is the name of the referent. + |
+ true | +
| group | +string | +
+ Group is the group of the referent. For example, "gateway.networking.k8s.io".
+When unspecified or empty string, core API group is inferred. + + Default: + |
+ false | +
| kind | +string | +
+ Kind is the Kubernetes resource kind of the referent. For example
+"Service".
+
+Defaults to "Service" when not specified.
+
+ExternalName services can refer to CNAME DNS records that may live
+outside of the cluster and as such are difficult to reason about in
+terms of conformance. They also may not be safe to forward to (see
+CVE-2021-25740 for more information). Implementations SHOULD NOT
+support ExternalName Services.
+
+Support: Core (Services with a type other than ExternalName)
+
+Support: Implementation-specific (Services with type ExternalName) + + Default: Service + |
+ false | +
| namespace | +string | +
+ Namespace is the namespace of the backend. When unspecified, the local
+namespace is inferred.
+
+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.
+
+Support: Core + |
+ false | +
| port | +integer | +
+ Port specifies the destination port number to use for this resource.
+Port is required when the referent is a Kubernetes Service. In this
+case, the port number is the service port number, not the target port.
+For other resources, destination port might be derived from the referent
+resource or this field. + + Format: int32 + Minimum: 1 + Maximum: 65535 + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| numerator | +integer | +
+ + + Format: int32 + Minimum: 0 + |
+ true | +
| denominator | +integer | +
+ + + Format: int32 + Default: 100 + Minimum: 1 + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| hostname | +string | +
+ Hostname is the hostname to be used in the value of the `Location`
+header in the response.
+When empty, the hostname in the `Host` header of the request is used.
+
+Support: Core + |
+ false | +
| path | +object | +
+ 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 + + Validations: |
+ false | +
| port | +integer | +
+ Port is the port to be used in the value of the `Location`
+header in the response.
+
+If no port is specified, the redirect port MUST be derived using the
+following rules:
+
+* If redirect scheme is not-empty, the redirect port MUST be the well-known
+ port associated with the redirect scheme. Specifically "http" to port 80
+ and "https" to port 443. If the redirect scheme does not have a
+ well-known port, the listener port of the Gateway SHOULD be used.
+* If redirect scheme is empty, the redirect port MUST be the Gateway
+ Listener port.
+
+Implementations SHOULD NOT add the port number in the 'Location'
+header in the following cases:
+
+* A Location header that will use HTTP (whether that is determined via
+ the Listener protocol or the Scheme field) _and_ use port 80.
+* A Location header that will use HTTPS (whether that is determined via
+ the Listener protocol or the Scheme field) _and_ use port 443.
+
+Support: Extended + + Format: int32 + Minimum: 1 + Maximum: 65535 + |
+ false | +
| scheme | +enum | +
+ Scheme is the scheme to be used in the value of the `Location` header in
+the response. When empty, the scheme of the request is used.
+
+Scheme redirects can affect the port of the redirect, for more information,
+refer to the documentation for the port field of this filter.
+
+Note that values may be added to this enum, implementations
+must ensure that unknown values will not cause a crash.
+
+Unknown values here must result in the implementation setting the
+Accepted Condition for the Route to `status: False`, with a
+Reason of `UnsupportedValue`.
+
+Support: Extended + + Enum: http, https + |
+ false | +
| statusCode | +integer | +
+ StatusCode is the HTTP status code to be used in response.
+
+Note that values may be added to this enum, implementations
+must ensure that unknown values will not cause a crash.
+
+Unknown values here must result in the implementation setting the
+Accepted Condition for the Route to `status: False`, with a
+Reason of `UnsupportedValue`.
+
+Support: Core + + Enum: 301, 302 + Default: 302 + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| type | +enum | +
+ Type defines the type of path modifier. Additional types may be
+added in a future release of the API.
+
+Note that values may be added to this enum, implementations
+must ensure that unknown values will not cause a crash.
+
+Unknown values here must result in the implementation setting the
+Accepted Condition for the Route to `status: False`, with a
+Reason of `UnsupportedValue`. + + Enum: ReplaceFullPath, ReplacePrefixMatch + |
+ true | +
| replaceFullPath | +string | +
+ ReplaceFullPath specifies the value with which to replace the full path
+of a request during a rewrite or redirect. + |
+ false | +
| replacePrefixMatch | +string | +
+ ReplacePrefixMatch specifies the value with which to replace the prefix
+match of a request during a rewrite or redirect. For example, a request
+to "/foo/bar" with a prefix match of "/foo" and a ReplacePrefixMatch
+of "/xyz" would be modified to "/xyz/bar".
+
+Note that this matches the behavior of the PathPrefix match type. This
+matches full path elements. A path element refers to the list of labels
+in the path split by the `/` separator. When specified, a trailing `/` is
+ignored. For example, the paths `/abc`, `/abc/`, and `/abc/def` would all
+match the prefix `/abc`, but the path `/abcd` would not.
+
+ReplacePrefixMatch is only compatible with a `PathPrefix` HTTPRouteMatch.
+Using any other HTTPRouteMatch type on the same HTTPRouteRule will result in
+the implementation setting the Accepted Condition for the Route to `status: False`.
+
+Request Path | Prefix Match | Replace Prefix | Modified Path + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| add | +[]object | +
+ Add adds the given header(s) (name, value) to the request
+before the action. It appends to any existing values associated
+with the header name.
+
+Input:
+ GET /foo HTTP/1.1
+ my-header: foo
+
+Config:
+ add:
+ - name: "my-header"
+ value: "bar,baz"
+
+Output:
+ GET /foo HTTP/1.1
+ my-header: foo,bar,baz + |
+ false | +
| remove | +[]string | +
+ Remove the given header(s) from the HTTP request before the action. The
+value of Remove is a list of HTTP header names. Note that the header
+names are case-insensitive (see
+https://datatracker.ietf.org/doc/html/rfc2616#section-4.2).
+
+Input:
+ GET /foo HTTP/1.1
+ my-header1: foo
+ my-header2: bar
+ my-header3: baz
+
+Config:
+ remove: ["my-header1", "my-header3"]
+
+Output:
+ GET /foo HTTP/1.1
+ my-header2: bar + |
+ false | +
| set | +[]object | +
+ Set overwrites the request with the given header (name, value)
+before the action.
+
+Input:
+ GET /foo HTTP/1.1
+ my-header: foo
+
+Config:
+ set:
+ - name: "my-header"
+ value: "bar"
+
+Output:
+ GET /foo HTTP/1.1
+ my-header: bar + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| name | +string | +
+ Name is the name of the HTTP Header to be matched. Name matching MUST be
+case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2).
+
+If multiple entries specify equivalent header names, the first entry with
+an equivalent name MUST be considered for a match. Subsequent entries
+with an equivalent header name MUST be ignored. Due to the
+case-insensitivity of header names, "foo" and "Foo" are considered
+equivalent. + |
+ true | +
| value | +string | +
+ Value is the value of HTTP Header to be matched. + |
+ true | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| name | +string | +
+ Name is the name of the HTTP Header to be matched. Name matching MUST be
+case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2).
+
+If multiple entries specify equivalent header names, the first entry with
+an equivalent name MUST be considered for a match. Subsequent entries
+with an equivalent header name MUST be ignored. Due to the
+case-insensitivity of header names, "foo" and "Foo" are considered
+equivalent. + |
+ true | +
| value | +string | +
+ Value is the value of HTTP Header to be matched. + |
+ true | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| hostname | +string | +
+ Hostname is the value to be used to replace the Host header value during
+forwarding.
+
+Support: Extended + |
+ false | +
| path | +object | +
+ Path defines a path rewrite.
+
+Support: Extended + + Validations: |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| type | +enum | +
+ Type defines the type of path modifier. Additional types may be
+added in a future release of the API.
+
+Note that values may be added to this enum, implementations
+must ensure that unknown values will not cause a crash.
+
+Unknown values here must result in the implementation setting the
+Accepted Condition for the Route to `status: False`, with a
+Reason of `UnsupportedValue`. + + Enum: ReplaceFullPath, ReplacePrefixMatch + |
+ true | +
| replaceFullPath | +string | +
+ ReplaceFullPath specifies the value with which to replace the full path
+of a request during a rewrite or redirect. + |
+ false | +
| replacePrefixMatch | +string | +
+ ReplacePrefixMatch specifies the value with which to replace the prefix
+match of a request during a rewrite or redirect. For example, a request
+to "/foo/bar" with a prefix match of "/foo" and a ReplacePrefixMatch
+of "/xyz" would be modified to "/xyz/bar".
+
+Note that this matches the behavior of the PathPrefix match type. This
+matches full path elements. A path element refers to the list of labels
+in the path split by the `/` separator. When specified, a trailing `/` is
+ignored. For example, the paths `/abc`, `/abc/`, and `/abc/def` would all
+match the prefix `/abc`, but the path `/abcd` would not.
+
+ReplacePrefixMatch is only compatible with a `PathPrefix` HTTPRouteMatch.
+Using any other HTTPRouteMatch type on the same HTTPRouteRule will result in
+the implementation setting the Accepted Condition for the Route to `status: False`.
+
+Request Path | Prefix Match | Replace Prefix | Modified Path + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| type | +enum | +
+ Type identifies the type of filter to apply. As with other API fields,
+types are classified into three conformance levels:
+
+- Core: Filter types and their corresponding configuration defined by
+ "Support: Core" in this package, e.g. "RequestHeaderModifier". All
+ implementations must support core filters.
+
+- Extended: Filter types and their corresponding configuration defined by
+ "Support: Extended" in this package, e.g. "RequestMirror". Implementers
+ are encouraged to support extended filters.
+
+- Implementation-specific: Filters that are defined and supported by
+ specific vendors.
+ In the future, filters showing convergence in behavior across multiple
+ implementations will be considered for inclusion in extended or core
+ conformance levels. Filter-specific configuration for such filters
+ is specified using the ExtensionRef field. `Type` should be set to
+ "ExtensionRef" for custom filters.
+
+Implementers are encouraged to define custom implementation types to
+extend the core API with implementation-specific behavior.
+
+If a reference to a custom filter type cannot be resolved, the filter
+MUST NOT be skipped. Instead, requests that would have been processed by
+that filter MUST receive a HTTP error response.
+
+Note that values may be added to this enum, implementations
+must ensure that unknown values will not cause a crash.
+
+Unknown values here must result in the implementation setting the
+Accepted Condition for the Route to `status: False`, with a
+Reason of `UnsupportedValue`.
+
+ + + Enum: RequestHeaderModifier, ResponseHeaderModifier, RequestMirror, RequestRedirect, URLRewrite, ExtensionRef + |
+ true | +
| cors | +object | +
+ CORS defines a schema for a filter that responds to the
+cross-origin request based on HTTP response header.
+
+Support: Extended
+
+ + |
+ false | +
| extensionRef | +object | +
+ 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 + |
+ false | +
| requestHeaderModifier | +object | +
+ RequestHeaderModifier defines a schema for a filter that modifies request
+headers.
+
+Support: Core + |
+ false | +
| requestMirror | +object | +
+ 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 + + Validations: |
+ false | +
| requestRedirect | +object | +
+ RequestRedirect defines a schema for a filter that responds to the
+request with an HTTP redirection.
+
+Support: Core + |
+ false | +
| responseHeaderModifier | +object | +
+ ResponseHeaderModifier defines a schema for a filter that modifies response
+headers.
+
+Support: Extended + |
+ false | +
| urlRewrite | +object | +
+ URLRewrite defines a schema for a filter that modifies a request during forwarding.
+
+Support: Extended + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| allowCredentials | +boolean | +
+ AllowCredentials indicates whether the actual cross-origin request allows
+to include credentials.
+
+The only valid value for the `Access-Control-Allow-Credentials` response
+header is true (case-sensitive).
+
+If the credentials are not allowed in cross-origin requests, the gateway
+will omit the header `Access-Control-Allow-Credentials` entirely rather
+than setting its value to false.
+
+Support: Extended + + Enum: true + |
+ false | +
| allowHeaders | +[]string | +
+ AllowHeaders indicates which HTTP request headers are supported for
+accessing the requested resource.
+
+Header names are not case sensitive.
+
+Multiple header names in the value of the `Access-Control-Allow-Headers`
+response header are separated by a comma (",").
+
+When the `AllowHeaders` field is configured with one or more headers, the
+gateway must return the `Access-Control-Allow-Headers` response header
+which value is present in the `AllowHeaders` field.
+
+If any header name in the `Access-Control-Request-Headers` request header
+is not included in the list of header names specified by the response
+header `Access-Control-Allow-Headers`, it will present an error on the
+client side.
+
+If any header name in the `Access-Control-Allow-Headers` response header
+does not recognize by the client, it will also occur an error on the
+client side.
+
+A wildcard indicates that the requests with all HTTP headers are allowed.
+The `Access-Control-Allow-Headers` response header can only use `*`
+wildcard as value when the `AllowCredentials` field is unspecified.
+
+When the `AllowCredentials` field is specified and `AllowHeaders` field
+specified with the `*` wildcard, the gateway must specify one or more
+HTTP headers in the value of the `Access-Control-Allow-Headers` response
+header. The value of the header `Access-Control-Allow-Headers` is same as
+the `Access-Control-Request-Headers` header provided by the client. If
+the header `Access-Control-Request-Headers` is not included in the
+request, the gateway will omit the `Access-Control-Allow-Headers`
+response header, instead of specifying the `*` wildcard. A Gateway
+implementation may choose to add implementation-specific default headers.
+
+Support: Extended + |
+ false | +
| allowMethods | +[]enum | +
+ AllowMethods indicates which HTTP methods are supported for accessing the
+requested resource.
+
+Valid values are any method defined by RFC9110, along with the special
+value `*`, which represents all HTTP methods are allowed.
+
+Method names are case sensitive, so these values are also case-sensitive.
+(See https://www.rfc-editor.org/rfc/rfc2616#section-5.1.1)
+
+Multiple method names in the value of the `Access-Control-Allow-Methods`
+response header are separated by a comma (",").
+
+A CORS-safelisted method is a method that is `GET`, `HEAD`, or `POST`.
+(See https://fetch.spec.whatwg.org/#cors-safelisted-method) The
+CORS-safelisted methods are always allowed, regardless of whether they
+are specified in the `AllowMethods` field.
+
+When the `AllowMethods` field is configured with one or more methods, the
+gateway must return the `Access-Control-Allow-Methods` response header
+which value is present in the `AllowMethods` field.
+
+If the HTTP method of the `Access-Control-Request-Method` request header
+is not included in the list of methods specified by the response header
+`Access-Control-Allow-Methods`, it will present an error on the client
+side.
+
+The `Access-Control-Allow-Methods` response header can only use `*`
+wildcard as value when the `AllowCredentials` field is unspecified.
+
+When the `AllowCredentials` field is specified and `AllowMethods` field
+specified with the `*` wildcard, the gateway must specify one HTTP method
+in the value of the Access-Control-Allow-Methods response header. The
+value of the header `Access-Control-Allow-Methods` is same as the
+`Access-Control-Request-Method` header provided by the client. If the
+header `Access-Control-Request-Method` is not included in the request,
+the gateway will omit the `Access-Control-Allow-Methods` response header,
+instead of specifying the `*` wildcard. A Gateway implementation may
+choose to add implementation-specific default methods.
+
+Support: Extended + + Validations: + |
+ false | +
| allowOrigins | +[]string | +
+ AllowOrigins indicates whether the response can be shared with requested
+resource from the given `Origin`.
+
+The `Origin` consists of a scheme and a host, with an optional port, and
+takes the form ` + |
+ false | +
| exposeHeaders | +[]string | +
+ ExposeHeaders indicates which HTTP response headers can be exposed
+to client-side scripts in response to a cross-origin request.
+
+A CORS-safelisted response header is an HTTP header in a CORS response
+that it is considered safe to expose to the client scripts.
+The CORS-safelisted response headers include the following headers:
+`Cache-Control`
+`Content-Language`
+`Content-Length`
+`Content-Type`
+`Expires`
+`Last-Modified`
+`Pragma`
+(See https://fetch.spec.whatwg.org/#cors-safelisted-response-header-name)
+The CORS-safelisted response headers are exposed to client by default.
+
+When an HTTP header name is specified using the `ExposeHeaders` field,
+this additional header will be exposed as part of the response to the
+client.
+
+Header names are not case sensitive.
+
+Multiple header names in the value of the `Access-Control-Expose-Headers`
+response header are separated by a comma (",").
+
+A wildcard indicates that the responses with all HTTP headers are exposed
+to clients. The `Access-Control-Expose-Headers` response header can only
+use `*` wildcard as value when the `AllowCredentials` field is
+unspecified.
+
+Support: Extended + |
+ false | +
| maxAge | +integer | +
+ MaxAge indicates the duration (in seconds) for the client to cache the
+results of a "preflight" request.
+
+The information provided by the `Access-Control-Allow-Methods` and
+`Access-Control-Allow-Headers` response headers can be cached by the
+client until the time specified by `Access-Control-Max-Age` elapses.
+
+The default value of `Access-Control-Max-Age` response header is 5
+(seconds). + + Format: int32 + Default: 5 + Minimum: 1 + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| group | +string | +
+ Group is the group of the referent. For example, "gateway.networking.k8s.io".
+When unspecified or empty string, core API group is inferred. + |
+ true | +
| kind | +string | +
+ Kind is kind of the referent. For example "HTTPRoute" or "Service". + |
+ true | +
| name | +string | +
+ Name is the name of the referent. + |
+ true | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| add | +[]object | +
+ Add adds the given header(s) (name, value) to the request
+before the action. It appends to any existing values associated
+with the header name.
+
+Input:
+ GET /foo HTTP/1.1
+ my-header: foo
+
+Config:
+ add:
+ - name: "my-header"
+ value: "bar,baz"
+
+Output:
+ GET /foo HTTP/1.1
+ my-header: foo,bar,baz + |
+ false | +
| remove | +[]string | +
+ Remove the given header(s) from the HTTP request before the action. The
+value of Remove is a list of HTTP header names. Note that the header
+names are case-insensitive (see
+https://datatracker.ietf.org/doc/html/rfc2616#section-4.2).
+
+Input:
+ GET /foo HTTP/1.1
+ my-header1: foo
+ my-header2: bar
+ my-header3: baz
+
+Config:
+ remove: ["my-header1", "my-header3"]
+
+Output:
+ GET /foo HTTP/1.1
+ my-header2: bar + |
+ false | +
| set | +[]object | +
+ Set overwrites the request with the given header (name, value)
+before the action.
+
+Input:
+ GET /foo HTTP/1.1
+ my-header: foo
+
+Config:
+ set:
+ - name: "my-header"
+ value: "bar"
+
+Output:
+ GET /foo HTTP/1.1
+ my-header: bar + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| name | +string | +
+ Name is the name of the HTTP Header to be matched. Name matching MUST be
+case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2).
+
+If multiple entries specify equivalent header names, the first entry with
+an equivalent name MUST be considered for a match. Subsequent entries
+with an equivalent header name MUST be ignored. Due to the
+case-insensitivity of header names, "foo" and "Foo" are considered
+equivalent. + |
+ true | +
| value | +string | +
+ Value is the value of HTTP Header to be matched. + |
+ true | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| name | +string | +
+ Name is the name of the HTTP Header to be matched. Name matching MUST be
+case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2).
+
+If multiple entries specify equivalent header names, the first entry with
+an equivalent name MUST be considered for a match. Subsequent entries
+with an equivalent header name MUST be ignored. Due to the
+case-insensitivity of header names, "foo" and "Foo" are considered
+equivalent. + |
+ true | +
| value | +string | +
+ Value is the value of HTTP Header to be matched. + |
+ true | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| backendRef | +object | +
+ 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 + + Validations: |
+ true | +
| fraction | +object | +
+ Fraction represents the fraction of requests that should be
+mirrored to BackendRef.
+
+Only one of Fraction or Percent may be specified. If neither field
+is specified, 100% of requests will be mirrored. + + Validations: |
+ false | +
| percent | +integer | +
+ Percent represents the percentage of requests that should be
+mirrored to BackendRef. Its minimum value is 0 (indicating 0% of
+requests) and its maximum value is 100 (indicating 100% of requests).
+
+Only one of Fraction or Percent may be specified. If neither field
+is specified, 100% of requests will be mirrored. + + Format: int32 + Minimum: 0 + Maximum: 100 + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| name | +string | +
+ Name is the name of the referent. + |
+ true | +
| group | +string | +
+ Group is the group of the referent. For example, "gateway.networking.k8s.io".
+When unspecified or empty string, core API group is inferred. + + Default: + |
+ false | +
| kind | +string | +
+ Kind is the Kubernetes resource kind of the referent. For example
+"Service".
+
+Defaults to "Service" when not specified.
+
+ExternalName services can refer to CNAME DNS records that may live
+outside of the cluster and as such are difficult to reason about in
+terms of conformance. They also may not be safe to forward to (see
+CVE-2021-25740 for more information). Implementations SHOULD NOT
+support ExternalName Services.
+
+Support: Core (Services with a type other than ExternalName)
+
+Support: Implementation-specific (Services with type ExternalName) + + Default: Service + |
+ false | +
| namespace | +string | +
+ Namespace is the namespace of the backend. When unspecified, the local
+namespace is inferred.
+
+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.
+
+Support: Core + |
+ false | +
| port | +integer | +
+ Port specifies the destination port number to use for this resource.
+Port is required when the referent is a Kubernetes Service. In this
+case, the port number is the service port number, not the target port.
+For other resources, destination port might be derived from the referent
+resource or this field. + + Format: int32 + Minimum: 1 + Maximum: 65535 + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| numerator | +integer | +
+ + + Format: int32 + Minimum: 0 + |
+ true | +
| denominator | +integer | +
+ + + Format: int32 + Default: 100 + Minimum: 1 + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| hostname | +string | +
+ Hostname is the hostname to be used in the value of the `Location`
+header in the response.
+When empty, the hostname in the `Host` header of the request is used.
+
+Support: Core + |
+ false | +
| path | +object | +
+ 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 + + Validations: |
+ false | +
| port | +integer | +
+ Port is the port to be used in the value of the `Location`
+header in the response.
+
+If no port is specified, the redirect port MUST be derived using the
+following rules:
+
+* If redirect scheme is not-empty, the redirect port MUST be the well-known
+ port associated with the redirect scheme. Specifically "http" to port 80
+ and "https" to port 443. If the redirect scheme does not have a
+ well-known port, the listener port of the Gateway SHOULD be used.
+* If redirect scheme is empty, the redirect port MUST be the Gateway
+ Listener port.
+
+Implementations SHOULD NOT add the port number in the 'Location'
+header in the following cases:
+
+* A Location header that will use HTTP (whether that is determined via
+ the Listener protocol or the Scheme field) _and_ use port 80.
+* A Location header that will use HTTPS (whether that is determined via
+ the Listener protocol or the Scheme field) _and_ use port 443.
+
+Support: Extended + + Format: int32 + Minimum: 1 + Maximum: 65535 + |
+ false | +
| scheme | +enum | +
+ Scheme is the scheme to be used in the value of the `Location` header in
+the response. When empty, the scheme of the request is used.
+
+Scheme redirects can affect the port of the redirect, for more information,
+refer to the documentation for the port field of this filter.
+
+Note that values may be added to this enum, implementations
+must ensure that unknown values will not cause a crash.
+
+Unknown values here must result in the implementation setting the
+Accepted Condition for the Route to `status: False`, with a
+Reason of `UnsupportedValue`.
+
+Support: Extended + + Enum: http, https + |
+ false | +
| statusCode | +integer | +
+ StatusCode is the HTTP status code to be used in response.
+
+Note that values may be added to this enum, implementations
+must ensure that unknown values will not cause a crash.
+
+Unknown values here must result in the implementation setting the
+Accepted Condition for the Route to `status: False`, with a
+Reason of `UnsupportedValue`.
+
+Support: Core + + Enum: 301, 302 + Default: 302 + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| type | +enum | +
+ Type defines the type of path modifier. Additional types may be
+added in a future release of the API.
+
+Note that values may be added to this enum, implementations
+must ensure that unknown values will not cause a crash.
+
+Unknown values here must result in the implementation setting the
+Accepted Condition for the Route to `status: False`, with a
+Reason of `UnsupportedValue`. + + Enum: ReplaceFullPath, ReplacePrefixMatch + |
+ true | +
| replaceFullPath | +string | +
+ ReplaceFullPath specifies the value with which to replace the full path
+of a request during a rewrite or redirect. + |
+ false | +
| replacePrefixMatch | +string | +
+ ReplacePrefixMatch specifies the value with which to replace the prefix
+match of a request during a rewrite or redirect. For example, a request
+to "/foo/bar" with a prefix match of "/foo" and a ReplacePrefixMatch
+of "/xyz" would be modified to "/xyz/bar".
+
+Note that this matches the behavior of the PathPrefix match type. This
+matches full path elements. A path element refers to the list of labels
+in the path split by the `/` separator. When specified, a trailing `/` is
+ignored. For example, the paths `/abc`, `/abc/`, and `/abc/def` would all
+match the prefix `/abc`, but the path `/abcd` would not.
+
+ReplacePrefixMatch is only compatible with a `PathPrefix` HTTPRouteMatch.
+Using any other HTTPRouteMatch type on the same HTTPRouteRule will result in
+the implementation setting the Accepted Condition for the Route to `status: False`.
+
+Request Path | Prefix Match | Replace Prefix | Modified Path + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| add | +[]object | +
+ Add adds the given header(s) (name, value) to the request
+before the action. It appends to any existing values associated
+with the header name.
+
+Input:
+ GET /foo HTTP/1.1
+ my-header: foo
+
+Config:
+ add:
+ - name: "my-header"
+ value: "bar,baz"
+
+Output:
+ GET /foo HTTP/1.1
+ my-header: foo,bar,baz + |
+ false | +
| remove | +[]string | +
+ Remove the given header(s) from the HTTP request before the action. The
+value of Remove is a list of HTTP header names. Note that the header
+names are case-insensitive (see
+https://datatracker.ietf.org/doc/html/rfc2616#section-4.2).
+
+Input:
+ GET /foo HTTP/1.1
+ my-header1: foo
+ my-header2: bar
+ my-header3: baz
+
+Config:
+ remove: ["my-header1", "my-header3"]
+
+Output:
+ GET /foo HTTP/1.1
+ my-header2: bar + |
+ false | +
| set | +[]object | +
+ Set overwrites the request with the given header (name, value)
+before the action.
+
+Input:
+ GET /foo HTTP/1.1
+ my-header: foo
+
+Config:
+ set:
+ - name: "my-header"
+ value: "bar"
+
+Output:
+ GET /foo HTTP/1.1
+ my-header: bar + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| name | +string | +
+ Name is the name of the HTTP Header to be matched. Name matching MUST be
+case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2).
+
+If multiple entries specify equivalent header names, the first entry with
+an equivalent name MUST be considered for a match. Subsequent entries
+with an equivalent header name MUST be ignored. Due to the
+case-insensitivity of header names, "foo" and "Foo" are considered
+equivalent. + |
+ true | +
| value | +string | +
+ Value is the value of HTTP Header to be matched. + |
+ true | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| name | +string | +
+ Name is the name of the HTTP Header to be matched. Name matching MUST be
+case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2).
+
+If multiple entries specify equivalent header names, the first entry with
+an equivalent name MUST be considered for a match. Subsequent entries
+with an equivalent header name MUST be ignored. Due to the
+case-insensitivity of header names, "foo" and "Foo" are considered
+equivalent. + |
+ true | +
| value | +string | +
+ Value is the value of HTTP Header to be matched. + |
+ true | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| hostname | +string | +
+ Hostname is the value to be used to replace the Host header value during
+forwarding.
+
+Support: Extended + |
+ false | +
| path | +object | +
+ Path defines a path rewrite.
+
+Support: Extended + + Validations: |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| type | +enum | +
+ Type defines the type of path modifier. Additional types may be
+added in a future release of the API.
+
+Note that values may be added to this enum, implementations
+must ensure that unknown values will not cause a crash.
+
+Unknown values here must result in the implementation setting the
+Accepted Condition for the Route to `status: False`, with a
+Reason of `UnsupportedValue`. + + Enum: ReplaceFullPath, ReplacePrefixMatch + |
+ true | +
| replaceFullPath | +string | +
+ ReplaceFullPath specifies the value with which to replace the full path
+of a request during a rewrite or redirect. + |
+ false | +
| replacePrefixMatch | +string | +
+ ReplacePrefixMatch specifies the value with which to replace the prefix
+match of a request during a rewrite or redirect. For example, a request
+to "/foo/bar" with a prefix match of "/foo" and a ReplacePrefixMatch
+of "/xyz" would be modified to "/xyz/bar".
+
+Note that this matches the behavior of the PathPrefix match type. This
+matches full path elements. A path element refers to the list of labels
+in the path split by the `/` separator. When specified, a trailing `/` is
+ignored. For example, the paths `/abc`, `/abc/`, and `/abc/def` would all
+match the prefix `/abc`, but the path `/abcd` would not.
+
+ReplacePrefixMatch is only compatible with a `PathPrefix` HTTPRouteMatch.
+Using any other HTTPRouteMatch type on the same HTTPRouteRule will result in
+the implementation setting the Accepted Condition for the Route to `status: False`.
+
+Request Path | Prefix Match | Replace Prefix | Modified Path + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| headers | +[]object | +
+ Headers specifies HTTP request header matchers. Multiple match values are
+ANDed together, meaning, a request must match all the specified headers
+to select the route. + |
+ false | +
| method | +enum | +
+ Method specifies HTTP method matcher.
+When specified, this route will be matched only if the request has the
+specified method.
+
+Support: Extended + + Enum: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH + |
+ false | +
| path | +object | +
+ Path specifies a HTTP request path matcher. If this field is not
+specified, a default prefix match on the "/" path is provided. + + Validations: + |
+ false | +
| queryParams | +[]object | +
+ QueryParams specifies HTTP query parameter matchers. Multiple match
+values are ANDed together, meaning, a request must match all the
+specified query parameters to select the route.
+
+Support: Extended + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| name | +string | +
+ Name is the name of the HTTP Header to be matched. Name matching MUST be
+case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2).
+
+If multiple entries specify equivalent header names, only the first
+entry with an equivalent name MUST be considered for a match. Subsequent
+entries with an equivalent header name MUST be ignored. Due to the
+case-insensitivity of header names, "foo" and "Foo" are considered
+equivalent.
+
+When a header is repeated in an HTTP request, it is
+implementation-specific behavior as to how this is represented.
+Generally, proxies should follow the guidance from the RFC:
+https://www.rfc-editor.org/rfc/rfc7230.html#section-3.2.2 regarding
+processing a repeated header, with special handling for "Set-Cookie". + |
+ true | +
| value | +string | +
+ Value is the value of HTTP Header to be matched. + |
+ true | +
| type | +enum | +
+ Type specifies how to match against the value of the header.
+
+Support: Core (Exact)
+
+Support: Implementation-specific (RegularExpression)
+
+Since RegularExpression HeaderMatchType has implementation-specific
+conformance, implementations can support POSIX, PCRE or any other dialects
+of regular expressions. Please read the implementation's documentation to
+determine the supported dialect. + + Enum: Exact, RegularExpression + Default: Exact + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| type | +enum | +
+ Type specifies how to match against the path Value.
+
+Support: Core (Exact, PathPrefix)
+
+Support: Implementation-specific (RegularExpression) + + Enum: Exact, PathPrefix, RegularExpression + Default: PathPrefix + |
+ false | +
| value | +string | +
+ Value of the HTTP path to match against. + + Default: / + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| name | +string | +
+ Name is the name of the HTTP query param to be matched. This must be an
+exact string match. (See
+https://tools.ietf.org/html/rfc7230#section-2.7.3).
+
+If multiple entries specify equivalent query param names, only the first
+entry with an equivalent name MUST be considered for a match. Subsequent
+entries with an equivalent query param name MUST be ignored.
+
+If a query param is repeated in an HTTP request, the behavior is
+purposely left undefined, since different data planes have different
+capabilities. However, it is *recommended* that implementations should
+match against the first value of the param if the data plane supports it,
+as this behavior is expected in other load balancing contexts outside of
+the Gateway API.
+
+Users SHOULD NOT route traffic based on repeated query params to guard
+themselves against potential differences in the implementations. + |
+ true | +
| value | +string | +
+ Value is the value of HTTP query param to be matched. + |
+ true | +
| type | +enum | +
+ Type specifies how to match against the value of the query parameter.
+
+Support: Extended (Exact)
+
+Support: Implementation-specific (RegularExpression)
+
+Since RegularExpression QueryParamMatchType has Implementation-specific
+conformance, implementations can support POSIX, PCRE or any other
+dialects of regular expressions. Please read the implementation's
+documentation to determine the supported dialect. + + Enum: Exact, RegularExpression + Default: Exact + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| attempts | +integer | +
+ Attempts specifies the maximum number of times an individual request
+from the gateway to a backend should be retried.
+
+If the maximum number of retries has been attempted without a successful
+response from the backend, the Gateway MUST return an error.
+
+When this field is unspecified, the number of times to attempt to retry
+a backend request is implementation-specific.
+
+Support: Extended + |
+ false | +
| backoff | +string | +
+ Backoff specifies the minimum duration a Gateway should wait between
+retry attempts and is represented in Gateway API Duration formatting.
+
+For example, setting the `rules[].retry.backoff` field to the value
+`100ms` will cause a backend request to first be retried approximately
+100 milliseconds after timing out or receiving a response code configured
+to be retryable.
+
+An implementation MAY use an exponential or alternative backoff strategy
+for subsequent retry attempts, MAY cap the maximum backoff duration to
+some amount greater than the specified minimum, and MAY add arbitrary
+jitter to stagger requests, as long as unsuccessful backend requests are
+not retried before the configured minimum duration.
+
+If a Request timeout (`rules[].timeouts.request`) is configured on the
+route, the entire duration of the initial request and any retry attempts
+MUST not exceed the Request timeout duration. If any retry attempts are
+still in progress when the Request timeout duration has been reached,
+these SHOULD be canceled if possible and the Gateway MUST immediately
+return a timeout error.
+
+If a BackendRequest timeout (`rules[].timeouts.backendRequest`) is
+configured on the route, any retry attempts which reach the configured
+BackendRequest timeout duration without a response SHOULD be canceled if
+possible and the Gateway should wait for at least the specified backoff
+duration before attempting to retry the backend request again.
+
+If a BackendRequest timeout is _not_ configured on the route, retry
+attempts MAY time out after an implementation default duration, or MAY
+remain pending until a configured Request timeout or implementation
+default duration for total request time is reached.
+
+When this field is unspecified, the time to wait between retry attempts
+is implementation-specific.
+
+Support: Extended + |
+ false | +
| codes | +[]integer | +
+ Codes defines the HTTP response status codes for which a backend request
+should be retried.
+
+Support: Extended + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| absoluteTimeout | +string | +
+ AbsoluteTimeout defines the absolute timeout of the persistent
+session. Once the AbsoluteTimeout duration has elapsed, the
+session becomes invalid.
+
+Support: Extended + |
+ false | +
| cookieConfig | +object | +
+ CookieConfig provides configuration settings that are specific
+to cookie-based session persistence.
+
+Support: Core + |
+ false | +
| idleTimeout | +string | +
+ IdleTimeout defines the idle timeout of the persistent session.
+Once the session has been idle for more than the specified
+IdleTimeout duration, the session becomes invalid.
+
+Support: Extended + |
+ false | +
| sessionName | +string | +
+ SessionName defines the name of the persistent session token
+which may be reflected in the cookie or the header. Users
+should avoid reusing session names to prevent unintended
+consequences, such as rejection or unpredictable behavior.
+
+Support: Implementation-specific + |
+ false | +
| type | +enum | +
+ Type defines the type of session persistence such as through
+the use a header or cookie. Defaults to cookie based session
+persistence.
+
+Support: Core for "Cookie" type
+
+Support: Extended for "Header" type + + Enum: Cookie, Header + Default: Cookie + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| lifetimeType | +enum | +
+ LifetimeType specifies whether the cookie has a permanent or
+session-based lifetime. A permanent cookie persists until its
+specified expiry time, defined by the Expires or Max-Age cookie
+attributes, while a session cookie is deleted when the current
+session ends.
+
+When set to "Permanent", AbsoluteTimeout indicates the
+cookie's lifetime via the Expires or Max-Age cookie attributes
+and is required.
+
+When set to "Session", AbsoluteTimeout indicates the
+absolute lifetime of the cookie tracked by the gateway and
+is optional.
+
+Defaults to "Session".
+
+Support: Core for "Session" type
+
+Support: Extended for "Permanent" type + + Enum: Permanent, Session + Default: Session + |
+ false | +
| Name | +Type | +Description | +Required | +
|---|---|---|---|
| backendRequest | +string | +
+ BackendRequest specifies a timeout for an individual request from the gateway
+to a backend. This covers the time from when the request first starts being
+sent from the gateway to when the full response has been received from the backend.
+
+Setting a timeout to the zero duration (e.g. "0s") SHOULD disable the timeout
+completely. Implementations that cannot completely disable the timeout MUST
+instead interpret the zero duration as the longest possible value to which
+the timeout can be set.
+
+An entire client HTTP transaction with a gateway, covered by the Request timeout,
+may result in more than one call from the gateway to the destination backend,
+for example, if automatic retries are supported.
+
+The value of BackendRequest must be a Gateway API Duration string as defined by
+GEP-2257. When this field is unspecified, its behavior is implementation-specific;
+when specified, the value of BackendRequest must be no more than the value of the
+Request timeout (since the Request timeout encompasses the BackendRequest timeout).
+
+Support: Extended + |
+ false | +
| request | +string | +
+ Request specifies the maximum duration for a gateway to respond to an HTTP request.
+If the gateway has not been able to respond before this deadline is met, the gateway
+MUST return a timeout error.
+
+For example, setting the `rules.timeouts.request` field to the value `10s` in an
+`HTTPRoute` will cause a timeout if a client request is taking longer than 10 seconds
+to complete.
+
+Setting a timeout to the zero duration (e.g. "0s") SHOULD disable the timeout
+completely. Implementations that cannot completely disable the timeout MUST
+instead interpret the zero duration as the longest possible value to which
+the timeout can be set.
+
+This timeout is intended to cover as close to the whole request-response transaction
+as possible although an implementation MAY choose to start the timeout after the entire
+request stream has been received instead of immediately after the transaction is
+initiated by the client.
+
+The value of Request is a Gateway API Duration string as defined by GEP-2257. When this
+field is unspecified, request timeout behavior is implementation-specific.
+
+Support: Extended + |
+ false | +