Route via HTTP/2 Assertion
CA API Gateway supports HTTP/2 protocol for inbound and outbound data transfers. Inbound traffic is supported by the HTTP/2 transport protocol and outbound traffic is supported by Route via HTTP/2 assertion. You can manage HTTP/2 client configurations such as connection and proxy settings globally and use these configurations in the Route via HTTP/2 assertion.
Layer7 API Gatewaysupports HTTP/2 protocol for inbound and outbound data transfers. Inbound traffic is supported by the HTTP/2 transport protocol and outbound traffic is supported by Route via HTTP/2 assertion. You can manage HTTP/2 client configurations such as connection and proxy settings globally and use these configurations in the Route via HTTP/2 assertion.
The Route via HTTP/2 assertion supports the HTTP 2.0 standards.
By default, the Server Push option is disabled.
You can set timeout values for open HTTP/2 connections using cluster properties. For more information, see HTTP/2 Cluster Properties.
See Gateway System Properties for information about configuring system properties for this assertion.
Using the Assertion
To add an assertion, refer to Adding an Assertion for instructions on adding this assertion from
- Right-click "Route via HTTP/2" in the policy window and then selectHTTP/2 Routing Propertiesor double-click the assertion in the policy window.The assertion properties are displayed.
- Review the address in theURLfield to ensure that it is the correct URL for the service; make any changes if necessary. The Policy Manager verifies that the URL is well formed and that the hostname is valid in the DNS.For SOAP services published from a WSDL, you can click to reset the URL to the one specified during the service publication process.If the URL contains a valid host but invalid path, routing attempts are recorded as a Policy Violation in the service statistics. However if the host is unknown, the routing attempts are recorded as Routing Failures. For more information about service statistics, see "Dashboard - Service Metrics" in Gateway Dashboard.For greater flexibility in specifying the path, you can embed context variables within the URL. Be sure the context variables resolve to a valid URL.
- Choose theHTTP Methodto use from the drop-down list. The list includes the well known methods, but you can enter your own method if necessary (including specifying a context variable). The default setting of<Automatic>uses the HTTP method from the request (if present), otherwise it uses the POST method.
- Choose theHTTP Client Configurationfrom the drop-down list. By default,<Default Config>configuration is selected, which includes all the default settings. The drop-down list includes all the client configurations that are enabled in the Manage HTTP/2 Client Configurations.
- Configure theRequesttab.
- Choose the request source from the drop-down list. This is the message to send as the outbound request. It is normally the<Default Request>message, but you can select a Message context variable that has been defined in the current context.
- Select theCompress (GZIP)check box if you want to compress the request payload. This can improve performance and transfer times, especially if the payloads are large.The compression option is valid only when the service endpoint supports HTTP level compression using Content-Encoding: gzip.
- SelectAlways include request bodycheck box to to include the request body with the outbound request, even if the HTTP request method is one that normally would not include a body (for example, GET, HEAD, DELETE, or OPTIONS).Note:The following of redirects is disabled for the request when a request body is forcibly included, even if the request method (such as GET) would otherwise have followed them.Clear the check box to not forcibly include the request body with the outbound request. In this case, the request body is include only with HTTP request methods (such as POST, PUT) that normally include them.
- To modify or override the Content-Type in the request message before routing, select theDo not automatically include Content-Type headercheck box. To use the existing Content-Type from the request message, leave this option unselected.If you are overriding the Content-Type header, ensure that the Manage Transport Properties/Headers Assertion is also present in the policy. This assertion works in tandem with the Route via HTTP/2 assertion to give you complete control over your headers.
- Select the authentication method:AuthenticationDescriptionNoneSelect this option for anonymous services. No credentials are required. This option removes Authorization header from the request.BasicSelect this option for basic HTTP authentication. You are prompted to enter yourUser NameandPassword.You may specify context variables in the User Name and Password fields.DigestSelect this option to use theUser NameandPasswordvalues as Digest authentication credentials.From RequestSelect this option to use the HTTP basic authentication headers in the request.
- Configure theResponsetab.
- Select the reponse destination from theDestinationdrop-down list. This is where to save the response returned from the server. This normally goes into the<Default Response>message, but you can choose a destination from the drop-down list or enter a new Message context variable that will hold the response.The default variable name of "httpResponse" is just a suggestion; ensure this name is unique if you opt to use it. Refer to the context variable naming rules if you receive syntax errors.When saving the route response to a Message context variable, the response body and headers are saved to the variable, not the default response. The response returned back to the client is the default response, not the Message variable. The routing header rules should affect the headers saved to the Message variable in this case, not the headers returned to the client.
- Select theOverride maximum message sizecheck box to override the permitted maximum size of the routing message if necessary. By default, the maximum size is defined by theio.xmlPartMaxBytescluster property. You may reference a context variable when restricting to a specific size. Note that allowing response messages of unlimited size is not recommended.TheRestrict messages tosetting takes effect only if the Gateway further processes the response message. This setting (as well as theio.xmlPartMaxBytescluster property) doesnotapply if a response is streamed back to the client with no processing��required by the Gateway. (Response streaming is controlled by theio.HttpResponseStreamingcluster property.) To limit the size of the message sent back to the client, use the Limit Message Size Assertion.Under normal conditions, theRestrict messages tosetting applies to the compressed message size. But if there are assertions that must act on theuncompressedresponse (for example, Evaluate Response XPath Assertion, etc.), then theuncompressedresponse size applies. For example, the response size is set at 50KB and a 40KB compressed response arrives--that message passes normally. However if there are assertions that must act on the uncompressed response and the message expands to 90KB uncompressed, then it exceeds the 50KB size limit and the policy fails.
- SelectFail if target returns error status (>=400)based on the response from the downstream endpoint. The assertion will fail when the response read from the target contains an error status (>= 400). There is an exception to this rule: If the service for which the policy is associated with is published as a Web Service (not an XML application) and the target returns a response with the status 500 and the content is a SOAP fault, then the SOAP fault is accepted as a valid response to be propagated to the requestor.Note:If an error occurs while getting a response from the target, the assertion will fail.
- Configure theOthertab with miscellaneous HTTP routing settings. In theRequest WS-Security Header Handlingsection, specify how to handle the security header:
- Select theDon't modify the request Security headeroption to instruct the Gateway to leave the security header in the outgoing request message as-is. The security header in the request may still have been modified if the Gateway needed to decrypt any encrypted material during message processing. Use this setting if the protected service needs to do its own checking of the request's original security header, or if the protected service does not care whether its request messages have a security header. For best performance, use this setting whenever possible to minimize the amount of per-request message modification.
- Select theRemove processed Security header from request before routingoption to instruct the Gateway to remove any security header that was processed by the gateway before forwarding the request to the protected service. Use this setting when the protected service is not expecting security headers in the forwarded requests.
- Select theRemove Layer 7 actor and mustUnderstand attributes from processed Security headeroption to instruct the Gateway to remove the "mustUnderstand" attribute and 'Layer 7' actor from the security header in the outgoing message. Use this setting if the presence of the Layer 7 actor causes issues with the back-end service. In certain cases, this actor may cause the back-end service to ignore the Security headers because it believes it is addressed to someone else. You will also use this setting if the back-end service does not support Security and would reject a request with "mustUnderstand" asserted on the Security header. An alternative might be to remove the Security header completely, however this will incur a performance penalty for the extra processing required to remove these from the messages. You may want to keep the Security headers intact for logging purposes.
- Select thePromote other security header as default before routingoption to instruct the Gateway to promote one of the downstream WSS recipients as the next default WSS header. Select the recipient from the drop-down list. This option is used primarily when the intended recipient of a WSS assertion does not accept or recognize security headers that contain Actor attributes.