Manage HTTP/2 Client Configurations

This option allows you to manage client configurations such as connection and proxy settings globally.
9-5
This option allows you to manage client configurations such as connection and proxy settings globally.
Note:
For information about the cluster properties used in the client configurations, see HTTP/2 Cluster Properties.
Follow these steps:
  1. Open Policy Manager and click
    Tasks
    ,
    Extensions and Add-Ons
    ,
    Manage HTTP/2 Client Configurations
    .
    The Manage HTTP/2 Client Configurations dialog opens listing all the existing configurations.
  2. Click
    Add
    to add a new configuration.
    The HTTP/2 Client Configuration Properties dialog opens.
  3. Enter a name to identify the client configuration.
  4. Add a description and select the
    Enabled
    check-box.
    Only the client configurations that are marked Enabled are listed in the
    HTTP/2 Routing Properties
    dialog in the assertion. For existing assertions that use these configurations, if the Enabled checkbox is cleared or if the client configuration is deleted, the assertion fails.
  5. Configure the
    Connection
    tab. The default settings provide a good starting point that work well in most instances. However the defaults are more conservative, which can result in slower and/or intermittent responses to the clients, depending on the availability of the configured back-end services. For improved responsiveness, consider the enhanced settings given below.
    1. The
      Connection Timeout
      defines the maximum time (in milliseconds) the Gateway attempts to establish a TCP connection. If exceeded, the routing will fail (or failover). To override the system default, clear the
      Use System Default
      check box and then enter a different value.
      The system default for this timeout is defined by the
      http2.routing.connectTimeout
      cluster property, which defaults to 1000 milliseconds if the property is not explicitly set.
      Configure the Connection Timeout proportionally to the distance or latency of your back-end services. For back-end services on the same physical server or rack, set Connection Timeout several milliseconds greater than the latency to that service. For example, if the back-end service has 10ms latency, the Connection Timeout should be approximately 20ms. For back-end services located overseas or on a different continent, make the Connection Timeout greater. This is to account for fluctuation in the network latency to that service over a larger physical distance. For example, if the back-end service has a 200ms latency, the Connection Timeout should be about 300ms.
    2. The
      Read Timeout
      defines the maximum time (in milliseconds) allowed for response data (not necessarily the complete response) to be read for the outbound request. If exceeded, the routing will fail (or failover). To override the system default, clear the
      Use System Default
      check box and enter a value.
      The system default for this timeout is defined by the
      http2.routing.readTimeout
      cluster property, which defaults to 5000 milliseconds if the property is not explicitly set.
      Note:
      The Read Timeout is triggered each time there is communication from the back-end server. As a result, it is possible that the actual communication time will be much longer than the value set for "Read Timeout".
      The Read Timeout should not exceed the SLA that is defined for your service. If a SLA is not defined, one should be created and communicated to your clients. If the client is expecting a response from the Gateway within 2000ms, the Read Timeout should be approximately 1500ms. It should never be greater than the SLA for the service, otherwise the Gateway would potentially fail the SLA if or when the back-end service is unavailable.
    3. Update
      Maximum Request Queue Size
      to control the maximum number of requests that can be queued before Gateway stops routing the incoming requests to the backend. For HTTP/2, this field is also used to decide the maximum threshold for concurrent streams over a single TCP connection. Generally, HTTP/2 host server decides this value, but you can choose to reduce the value as needed. If the field contains a different value than the one provided by HTTP/2 host server, then the final effective value is the minimum of these values. To override the system default, clear the
      Use System Default
      check box and enter a value. The system default for this timeout is defined by the
      http2.routing.maxRequestQueueSize
      cluster property, which defaults to 1024 if the property is not explicitly set.
    4. Update
      Maximum Host Connections
      to control the number of maximum TCP connections to a single host that is allowed by Gateway. To override the system default, clear the
      Use System Default
      check box and enter a value. The system default for this timeout is defined by the
      http2.routing.maxHostConnections
      cluster property, which defaults to 64 if the property is not explicitly set.
    5. Choose which
      TLS Version
      to allow when connecting via HTTP/2.
      HTTP/2 supports only TLSv1.2 and later.
      1. To use a specific set of TLS cipher suites for this HTTP connection, click [
        Cipher Suites
        ]. For more information, see Selecting Cipher Suites.
        When
        TLS 1.3
        option is selected, ensure that the following ciphers are enabled:
        • TLS_AES_256_GCM_SHA384
        • TLS_AES_128_GCM_SHA256
      2. To allow a subset of trusted certificates during the outbound TLS handshake, click [
        Trusted Server Certificates
        ] and then select:
        • Trust all Trusted Certificate:
          Trust all trusted certificates presently in the Gateway trust store. For more information, see Manage Certificates.
        • Trust only the specified Trusted Certificates:
          Trust only the trusted certificates in the table below. Only the certificates that you define here will be trusted during the outbound TLS handshake from this routing assertion
        As with all trusted certificates, the certificates in this list will be trusted only if their settings are compatible (for example, if it has been configured to be "trusted for outbound SSL").
        To disable hostname verification, update the cluster property, http2.disableHostnameVerification.
    6. Select the
      Follow Redirects
      check box to instruct the assertion to follow HTTP redirect responses from the downstream target. Otherwise, redirect responses are sent back to the requestor.
  6. Configure the
    Proxy
    tab. Select the
    Use Proxy
    check box to configure an HTTP proxy host, if required. When configuring a proxy host, enter the literal values for
    Host
    ,
    Port
    , and
    Username.
    Select the secure password that was created using Manage Stored Passwords.
    Note:
    Proxy for HTTPS backend is not supported.
  7. Click
    OK
    to save.