HttpRouteActionResponse

data class HttpRouteActionResponse(val corsPolicy: CorsPolicyResponse, val faultInjectionPolicy: HttpFaultInjectionResponse, val maxStreamDuration: DurationResponse, val requestMirrorPolicy: RequestMirrorPolicyResponse, val retryPolicy: HttpRetryPolicyResponse, val timeout: DurationResponse, val urlRewrite: UrlRewriteResponse, val weightedBackendServices: List<WeightedBackendServiceResponse>)

Constructors

Link copied to clipboard
fun HttpRouteActionResponse(corsPolicy: CorsPolicyResponse, faultInjectionPolicy: HttpFaultInjectionResponse, maxStreamDuration: DurationResponse, requestMirrorPolicy: RequestMirrorPolicyResponse, retryPolicy: HttpRetryPolicyResponse, timeout: DurationResponse, urlRewrite: UrlRewriteResponse, weightedBackendServices: List<WeightedBackendServiceResponse>)

Types

Link copied to clipboard
object Companion

Properties

Link copied to clipboard

The specification for allowing client-side cross-origin requests. For more information about the W3C recommendation for cross-origin resource sharing (CORS), see Fetch API Living Standard. Not supported when the URL map is bound to a target gRPC proxy.

Link copied to clipboard

The specification for fault injection introduced into traffic to test the resiliency of clients to backend service failure. As part of fault injection, when clients send requests to a backend service, delays can be introduced by a load balancer on a percentage of requests before sending those requests to the backend service. Similarly requests from clients can be aborted by the load balancer for a percentage of requests. timeout and retry_policy is ignored by clients that are configured with a fault_injection_policy if: 1. The traffic is generated by fault injection AND 2. The fault injection is not a delay fault injection. Fault injection is not supported with the global external HTTP(S) load balancer (classic). To see which load balancers support fault injection, see Load balancing: Routing and traffic management features.

Link copied to clipboard

Specifies the maximum duration (timeout) for streams on the selected route. Unlike the timeout field where the timeout duration starts from the time the request has been fully processed (known as end-of-stream), the duration in this field is computed from the beginning of the stream until the response has been processed, including all retries. A stream that does not complete in this duration is closed. If not specified, this field uses the maximum maxStreamDuration value among all backend services associated with the route. This field is only allowed if the Url map is used with backend services with loadBalancingScheme set to INTERNAL_SELF_MANAGED.

Link copied to clipboard

Specifies the policy on how requests intended for the route's backends are shadowed to a separate mirrored backend service. The load balancer does not wait for responses from the shadow service. Before sending traffic to the shadow service, the host / authority header is suffixed with -shadow. Not supported when the URL map is bound to a target gRPC proxy that has the validateForProxyless field set to true.

Link copied to clipboard

Specifies the retry policy associated with this route.

Link copied to clipboard

Specifies the timeout for the selected route. Timeout is computed from the time the request has been fully processed (known as end-of-stream) up until the response has been processed. Timeout includes all retries. If not specified, this field uses the largest timeout among all backend services associated with the route. Not supported when the URL map is bound to a target gRPC proxy that has validateForProxyless field set to true.

Link copied to clipboard

The spec to modify the URL of the request, before forwarding the request to the matched service. urlRewrite is the only action supported in UrlMaps for external HTTP(S) load balancers. Not supported when the URL map is bound to a target gRPC proxy that has the validateForProxyless field set to true.

Link copied to clipboard

A list of weighted backend services to send traffic to when a route match occurs. The weights determine the fraction of traffic that flows to their corresponding backend service. If all traffic needs to go to a single backend service, there must be one weightedBackendService with weight set to a non-zero number. After a backend service is identified and before forwarding the request to the backend service, advanced routing actions such as URL rewrites and header transformations are applied depending on additional settings specified in this HttpRouteAction.