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.
9-5
Layer7 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.
The Route via HTTP/2 assertion supports the HTTP 2.0 standards.
By default, the Server Push option is disabled.
Cluster Properties
You can set timeout values for open HTTP/2 connections using cluster properties. For more information, see HTTP/2 Cluster Properties.
System 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
Message Routing
under
Policy Assertions
.
  1. Right-click "
    Route via HTTP/2
    " in the policy window and then select
    HTTP/2 Routing Properties
    or double-click the assertion in the policy window.
    The assertion properties are displayed.
  2. Review the address in the
    URL
    field 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 Reset.png 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.
  3. Choose the
    HTTP Method
    to 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.
    If a custom HTTP method is present in the message being routed, it is passed through. For more information about HTTP Methods, refer to the "HTTP/FTP" tab of Published Service Properties.
  4. Choose the
    HTTP Client Configuration
    from 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.
  5. Configure the
    Request
    tab.
    1. 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.
    2. Select the
      Compress (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.
    3. Select
      Always include request body
      check 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.
    4. To modify or override the Content-Type in the request message before routing, select the
      Do not automatically include Content-Type header
      check 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.
    5. Select the authentication method:
      Authentication
      Description
      None
      Select this option for anonymous services. No credentials are required. This option removes Authorization header from the request.
      Basic
      Select this option for basic HTTP authentication. You are prompted to enter your
      User Name
      and
      Password
      .
      You may specify context variables in the User Name and Password fields.
      Digest
      Select this option to use the
      User Name
      and
      Password
      values as Digest authentication credentials.
      From Request
      Select this option to use the HTTP basic authentication headers in the request.
  6. Configure the
    Response
    tab.
    1. Select the reponse destination from the
      Destination
      drop-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.
    2. Select the
      Override maximum message size
      check box to override the permitted maximum size of the routing message if necessary. By default, the maximum size is defined by the
      io.xmlPartMaxBytes
      cluster property. You may reference a context variable when restricting to a specific size. Note that allowing response messages of unlimited size is not recommended.
      The
      Restrict messages to
      setting takes effect only if the Gateway further processes the response message. This setting (as well as the
      io.xmlPartMaxBytes
      cluster property) does
      not
      apply if a response is streamed back to the client with no processing��required by the Gateway. (Response streaming is controlled by the
      io.HttpResponseStreaming
      cluster property.) To limit the size of the message sent back to the client, use the Limit Message Size Assertion.
      Under normal conditions, the
      Restrict messages to
      setting applies to the compressed message size. But if there are assertions that must act on the
      uncompressed
      response (for example, Evaluate Response XPath Assertion, etc.), then the
      uncompressed
      response 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.
    3. Select
      Fail 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.
  7. Configure the
    Other
    tab with miscellaneous HTTP routing settings. In the
    Request WS-Security Header Handling
    section, specify how to handle the security header:
    1. Select the
      Don't modify the request Security header
      option 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.
      Do not modify the Security header if the policy uses WS-Security. For more information, see Add or Remove WS-Security Assertion.
    2. Select the
      Remove processed Security header from request before routing
      option 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.
    3. Select the
      Remove Layer 7 actor and mustUnderstand attributes from processed Security header
      option 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.
    4. Select the
      Promote other security header as default before routing
      option 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.
      For more information about changing the recipient of the available WSS (WS-Security) message-level assertions, see Change the WSS Assertion Recipient.
  8. Click
    OK
    .