Skip to content
CA API Gateway - 9.4
Documentation powered by DocOps

Route via HTTP(S) Assertion

Last update September 4, 2018

The Route via HTTP(S) assertion defines where a Web service or XML application message is sent and what authentication credentials it uses. If the service requests client authentication, the Gateway can be configured to respond in any number of ways:

  • By default, it uses the subject certificate from the default SSL to respond to the SSL-TLS handshake.
  • You can specify a custom private key to use. The Gateway uses the subject certificate from this private key to respond to outbound TLS client certificate challenges from the server.
  • You can configure the Gateway to decline all certificate challenges by selecting the "Use no private key" option when selecting a private key in this assertion. Tip: This option is unique to the Route via HTTP(S) assertion.

To learn more about selecting a private key for this assertion, see Select a Custom Private Key.

A message routing assertion is an essential policy element. When you publish a service using the Publish SOAP Web Service Wizard, Create WSDL Wizard, or Publish Web API Wizard (with a target URL), the Policy Manager automatically adds the service URL specified during the publication process as a Route via HTTP(S) assertion in the published service's initial policy.

Notes: (1) By default, the outbound HTTP method is passed through from the inbound request HTTP method. Where there is no inbound request method (for example, a context variable is used), then the POST action is used. (2) The Gateway does not support the use of elliptic curve certificates (ECC) as the client certificate for an outbound TLS connection.

The Route via HTTP(S) assertion supports the HTTP 1.0 and 1.1 standards. It should be present in policies that consume an external REST or HTTP-SOAP based API.

Tip: When routing failures to the back-end systems occur, CA Technologies recommends capturing those failure events through policy assertions and logic (Audit log, syslog, SMTP, SNMP, JMS, AMQP, etc.) This event handling captures the failure from the back-end services and allows the Gateway to return an intelligent response to the client that the back-end service is unavailable. During auditing and triage sessions of a service outage, a Gateway user can provide granular information for those specific failures to the back-end services

Using the Assertion

By default, the Policy Manager automatically adds a Route via HTTP(S) assertion to a new service policy created by one of the Publish Service wizards. If the assertion was removed or you need to add another one, refer to Adding an Assertion for instructions on adding this assertion.

  1. Right-click "Route via HTTP(S) to..." in the policy window and then select HTTP(S) Routing Properties or double-click the assertion in the policy window. The assertion properties are displayed.
  2. Review the address in the URL box 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. 

    Tip: For SOAP services published from a WSDL, you can click  to reset the URL to the one specified during the service publication process.

    Note: 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 is uses the POST method. 

    Tip: 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 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.
  5. Specify the Response Destination. 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. 

    Tip: 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.

    Note: 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.

  6. Configure each tab as necessary. Refer to the appropriate section below for a complete description of each tab.
  7. Click [OK] when done.

Configuring the [Authentication] Tab

In the [Authentication] tab, select an authentication method.

Authentication Description
None (Anonymous) Select this option for anonymous services. No credentials are required.

Use OAuth Authorization


Select this option to use OAuth Authorization for credentials. Choose the OAuth Version and then specify the Token Variable.

The OAuth version determines what is prepended to the contents of the token variable in the Authorization header value.

  • For OAuth 1.0, this is the equivalent of adding an Authorization header with the value "OAuth ${var}".
  • Otherwise, it is equivalent to adding an Authorization header with the value "Bearer ${var}".

Note: Ensure that the OAuth token has already been obtained and is present in the specified context variable.

Specify HTTP Credentials

Select this option for basic HTTP authentication. You are prompted to enter your User Name, Password, NTLM Domain, and NTLM Host.

You may specify context variables in the User Name and Password fields.

Notes: (1) If no credentials are entered, the authentication option reverts to "None (Anonymous)" the next time the [Authentication] tab is opened. (2) NTLM authentication is not supported when a proxy server is configured (see " Configure the [Proxy] Tab"). (3) Both NTLM v1 and v2 authentication are supported.

Use HTTP Credentials from Request

Select this option to use the HTTP basic or NTLM authentication headers in the request.

Technical Note: If you select this option, the com.l7tech.server.policy.assertion.ServerHttpRoutingAssertion.statePool.enable system property is disabled.

Attach SAML Sender-Vouches

Select this option to attach a SAML sender-vouches ticket to each outgoing back-end request that was authenticated by the Gateway. This ticket contains the user name of the authenticated user along with an expiration time, and is signed by the Gateway using the SSL certificate. You are prompted to specify the SAML Version and Ticket expiry time, in minutes (whole number only).

Note: The "Attach SAML Sender-Vouches" option is enabled only for SOAP Web service policies. It differs from the Require SAML Token Profile Assertion as follows:

  • The Attach SAML Sender-Vouches option is being added to the outgoing message from the Gateway to the protected service.
  • The Require SAML Token Profile Assertion requires that SAML security already be present in an incoming message from a client application to the Gateway.
Send TAI Header Select this option to require a Trust Association Interceptor (TAI) third-party authentication pass. TAI credential chaining can be used with or without a static user name and password. With TAI, if the Gateway authenticated a user, then the user name of that authenticated user is included in the IV_USER HTTP header in the outgoing request.
Use Windows Integrated

Select this option to enable outbound Kerberos Delegation via Windows Integrated Authentication. Specify how to proceed:

  • Use Delegated Credentials: Select this option to use the credentials extracted from the request Kerberos token to request a service ticket for routing. If using this option, one of the following assertions must be present in the policy: Require Windows Integrated Authentication Credentials or Require WS-Security Kerberos Token Profile Credentials.
  • Use Gateway Keytab: Select this option to use the kerberos.keytab file on the Gateway.
  • Use Configured Credentials: Select this option to have the assertion use the specified account to authenticate with the KDC and obtain a service ticket for routing.

Notes: (1) The "Use Gateway Keytab" and "Use Configured Credentials" options do not require Kerberos access control (in other words, the Require Windows Integrated Authentication Credentials or WSS Kerberos assertions are not required). Using the Require HTTP Basic Credential Assertion is sufficient. (2) Kerberos authentication is not supported when a proxy server is configured (see " Configure the [Proxy] Tab").

Configuring the [Headers] Tab

The [Headers] tab is used to define which HTTP headers should be passed through. It contains separate sections for request and response headers.

By default, all request and response headers are passed through in their original form. 

WARNING: There may be potential security ramifications to allowing all applications header to be passed through. If in doubt, restrict the pass-through to only specific headers.

When passing through only specific headers, define these headers in their respective tables. You can choose to pass the original value of the header or a custom value (context variables acceptable).

Some tips for constructing a list of headers to be passed through:

  • You may repeat header names if you are constructing multiple rules on handling a particular header. See "Working with Multiple Headers" below for more details.
  • When passing the original value, if the header is present multiple times in the incoming request, then it is passed multiple times as they are in the original request.
  • When passing through only specific request or response headers, if no headers are specified in the accompanying table, then the Gateway reverts to passing through all headers. 

The Gateway does not pass these headers by default, regardless of the pass-through rules defined

connection
content-encoding
content-length
content-type
date
host

keep-alive
server
transfer-encoding

Technical Note: To pass through any of the excluded headers above, add the system property com.l7tech.policy.assertion.HttpPassthroughRuleSet.headersToSkip with the list of headers to skip. For more information, see Gateway System Properties.

Overriding Headers

Be aware of the interaction between the Route via HTTP(S) assertion and the Manage Transport Properties/Headers Assertion. Header customizations may be overridden, depending on which assertion appears later in the policy.

The Manage Transport Properties/Headers Assertion is useful for manipulating custom HTTP headers in a message, especially for the headers that cannot be overridden by the Route via HTTP(S) assertion.

Example:

If you are hosting several different languages, you can set the appropriate charset using the Manage Transport Properties/Headers Assertion (this assumes the back end web server is set for charset=UTF-8). For example, to correctly display pages in Japanese, add the Manage Transport Properties/Headers Assertion immediately after the Route via HTTP(S) assertion. Use the following properties:

  • Type: HTTP Header
  • Operation: Add or Replace
  • Property/Header Name: Content-Type
  • Property/Header Value: text/html; charset=shift_jis

If the Japanese encodiing "euc-jp" is needed, then use the above settings with charset=euc-jp instead.

Working with Multiple Headers

It may be necessary to construct multiple rules to describe how you want to handle a particular header. For example, you wish to forward several custom values for a particular request or response header.

The following table summarizes the possible scenarios when you are passing through only certain headers.

Scenario What will happen
Define a header "ABC" with value = <original value> All headers with the name "ABC" are forwarded, with their original values intact.
Define a header "ABC" with value = "XYZ" A new header with name "ABC" with value "XYZ" is inserted.
Define the headers "ABC" = "123" and "ABC" = '456'. Two headers with name "ABC" are inserted: One with value "123" and another one with value "456".
Define the headers "ABC" = <original value> and "ABC" = "123". All headers with the name "ABC" are forwarded, with their original values intact. An additional header with the custom value "123" is inserted.

Working with HTTP Host Headers

The HTTP Host Header can be set a number of different ways. By default, this header is set to the URL hostname specified at the top of the properties dialog. You can enhance the flexibility of the Host Header by doing the following:

  1. Ensure you are passing through only certain request headers.
  2. Add a new request header with the name "Host".
  3. Select Customize Value, and then choose one of the following depending on how you wish to populate the Host Header:
    • leave the value blank: The HOST header in the HTTP request is populated with the Host name from the target URL.
    • enter a context variable: The HOST header in the HTTP request is populated with the value contained in the context variable.
    • any other non-blank value: The HOST header in the HTTP request is populated with the value entered here.

Configuring the [Connection] Tab

The [Connection] tab is used to configure failover strategies, timeouts, and TLS settings. 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. Specify how IP addresses should be retrieved:

    IP address option Description
    Look Up IP Addresses in DNS Select this option to have the Gateway retrieve the IP addresses from the Domain Name Server (DNS). This setting is the default and it does not use a failover strategy.
    Use the following IP addresses Select this option to have the Gateway only use IP addresses from the list that follows.  
    Use multiple URLs Select this option to have the Gateway sequentially use URLs from the list that follows. This option is useful if, for example, multiple instances of a service reside at different URLs rather than just different IP addresses.
    You may specify context variables when constructing a list of URLs using this option.
  2. Choose a Failover strategy to use in case an IP address or URL fails to respond:

    Failover Strategy Description
    Ordered Sticky with Failover

    The Gateway sends service messages to the first IP/URL in the list until that IP/URL does not respond (fails). When this occurs, the next IP/URL in the list is used.

    Tip: The cluster propertyio.failoverServerRetryDelay controls the delay before the Gateway retries a failed server. The default is to wait 15 minutes when using the "Ordered Sticky with Failover" strategy.

    Random Sticky with Failover The Gateway chooses an IP/URL randomly at the beginning of each session and uses it for the duration of the session. If the chosen IP/URL address fails, another IP/URL is chosen at random.
    Round Robin

    The Gateway rotates through the IP/URL list on a request-by-request basis (round-robin) from the first, to the second, and so on. When the end of the list is reached, the cycle continues from the top of the list.

    Tip: The cluster propertyio.failoverServerRetryDelay controls the delay before the Gateway retries a failed server. The default is to wait 5 minutes when using the "Round Robin" strategy.

  3. You can override any of the following timeout values for this routing assertion only:
    • 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. You may reference context variables.
      The system default for this timeout is defined by the io.outConnectTimeout cluster property, which defaults to 30 seconds if the property is not explicitly set.

      Tip:  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.

    • 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. You may reference context variables.
      The system default for this timeout is defined by the io.outTimeout cluster property, which defaults to 60 seconds 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".

      Tip: 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.

    • The Maximum Retries defines the maximum number of attempts, in addition to the initial attempt, to establish a TCP connection. For example, Maximum Retries = 3 means there will be 4 attempts: the initial attempt and 3 retry attempts. To override the system default, clear the Use System Default check box and enter a value between 0 and 100 (where "0" will prevent retries). The default is 3 retries.

      Tip: For best performance, configure Maximum Retries to "0" for no retries. The intelligence and logic to handle failures should be handled in the client and the Gateway should follow a "fail fast" model. Should the client not have built-in retry logic, enable 1 retry for only the HTTP GET method.

  4. Choose which TLS Version to allow when connecting via HTTPS. 

    Technical Note: If you choose "TLS 1.0 with SSLv2Hello", the Gateway will use SunJSSE as the TLS implementation for the outbound connection, even if SSL-J is available. This is because SSL-J does not support SSLv2Hello.

  5. To use a specific set of TLS cipher suites for this HTTP connection, click [Cipher Suites]. For more information, see Selecting Cipher Suites.
  6. 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

    Note: 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").

Configuring the [HTTP] Tab

The [HTTP] tab is used to further refine the settings for your HTTP protocol.

  1. Choose the Version from the drop-down list. The Default setting uses the version defined by the io.httpVersion cluster property (which is factory set at version 1.1). Select another version if you need to override the cluster property.
  2. Select the Compress Output check box if you want to compress the request payload. This can improve performance and transfer times, especially if the payloads are large. 

    Note: The compression option is valid only when the service endpoint supports HTTP level compression using Content-Encoding: gzip.

  3. Select the Use Keep-Alive check box to use persistent connections. These connections are more efficient, as they allow reuse of TCP connections for multiple messages. Clear this check box to not use persistent connections on this routing.

    Note: You can enable "keep-alive" only when the io.httpDisableKeepAlive cluster property is at its default "false" setting. If that property was set to "true", then "keep-alives" are disabled globally and cannot be enabled for an individual HTTP routing.

  4. 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.
  5. Select the Transmit body regardless of request method check box 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.

  6. To modify or override the Content-Type in the request message before routing, select the Do not automatically include Content-Type header in request 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(S) assertion to give you complete control over your headers. For a detailed description on how you can manipulate the Content-Type header during routing, see "Manipulating the Content-Type Header" below.
  7. (Available in 9.3 CR2 or higher) If you need to exclude the Host header from the request message, select the Omit Host header (for HTTP/1.0) check box. Otherwise, the Host header is included. Note that this setting is valid for HTTP 1.0 only. This setting is unavailable if "HTTP Version" is Default or 1.1. (Unless the default HTTP version is changed in the io.httpVersion cluster property.)
  8. Click Customize Request Form POST Parameters if you need to change how these parameters work. You will be able to:
    • Specify whether all request form Post parameters received from the requestor are passed through, or only certain ones.
    • Define a list of specific parameters to pass through. 

      Tips: (1) You may repeat parameter names if you are constructing multiple rules on handling a particular parameter. See " Working with Multiple Headers " earlier in this topic for more details. (2) If the parameter is present multiple times in the incoming request, then it is passed multiple times as they are in the original request.

Manipulating the Content-Type Header

You can control the Content-Type header during routing by using the Manage Transport Properties/Headers Assertion along with the Route via HTTP(S) assertion.

Example 1: Remove the Content-Type header from the request before routing

  1. Add the Route via HTTP(S) assertion to a policy and select Do not automatically include Content-Type header in request.
  2. Add the Manage Transport Properties/Headers Assertion before the Route via HTTP(S) assertion and set the target message to 'Request'. Configure the properties as follows:
    • Type: HTTP Header
    • Operation: Remove
    • Property/Header Name: Content-Type

The response does not contain the Content-Type header in the body of the reply message.

Example 2: Modify the Content-Type header before routing

  1. Add the Route via HTTP(S) assertion to a policy and select Do not automatically include Content-Type header in request.
  2. Add the Manage Transport Properties/Headers Assertion before the Route via HTTP(S) assertion and set the target message to 'Request'. Configure the properties as follows:
    • Type: HTTP Header
    • Operation: Add or Replace
    • Property/Header Name: Content-Type
    • Property/Header Value: application/my-content-type

The response contains the Content-Type header value set in the policy (application/my-content-type) in the body of the reply message.

Example 3: Add a Content-Type header before routing

  1. Add the Route via HTTP(S) assertion to a policy and select Do not automatically include Content-Type header in request.
  2. Add the Manage Transport Properties/Headers Assertion before the Route via HTTP(S) assertion and set the target message to 'Request'. Configure the properties as follows:
    • Type: HTTP Header
    • Operation: Add 
    • Property/Header Name: Content-Type
    • Property/Header Value: application/my-content-type

Results:

  • For a request with no Content-Type header and empty body: 
    • The response contains the Content-Type header value added in the policy (application/my-content-type) in the body of the reply message.
  • For a request with no Content-Type header and a non-empty body: 
    • The response contains the Content-Type header value added in the policy (application/my-content-type) and the value application/x-www-form-urlencoded in the body of the reply message.
  • For a request with Content-Type header 'text/xml' and a non-empty body:
    • The response contains the Content-Type header value added in the policy (application/my-content-type) and the value text/xml in the body of the reply message

Configuring the [Proxy] Tab

Note: When a proxy server is configured, the following authentication method cannot be used: Use Windows Integrated.

The [Proxy] tab is used to configure an HTTP proxy host, if required. 

When configuring a proxy host, enter the literal values or specify context variables:

  • Proxy Host: Enter the proxy host or reference one or more context variables.
  • Proxy Port: Enter the port number or reference a single context variable.
  • Proxy Username: Enter the username or reference one or more context variables.
  • Proxy Password: Enter the password or use a secure password reference (recommended). A simple context variable reference may not be used here.

    Tip: For best security, use a secure password reference instead of entering the actual password. To do this, first define your password using the Manage Stored Passwords task and then reference it here using the ${secpass.<name>.plaintext} context variable.

Configuring the [Other] Tab

The [Other] tab is used to configure miscellaneous HTTP routing settings.

  1. In the Request WSS Header Handling section, specify how to handle the security header:

    Option Description
    Don't modify the request Security header

    Instructs 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.

    Note: Do not modify the Security header if the policy uses WS-Security. For more information, see Add or Remove WS-Security Assertion

    Remove Layer 7 actor and mustUnderstand attributes from processed Security header

    Instructs 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.

    Remove processed Security header from request before routing

    Instructs 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.

    Promote other security header as default before routing

    Instructs 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.

  2. Under Response Size Limit, you may 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.

    Note: The Response Size Limit 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.

    Special note when working with compressed responses

    Under normal conditions, the Response Size Limit applies to the compressed message size. But if there are assertions that must act on the uncompressed response (for example, Evaluate Regular Expression Assertion, 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. Choose an Assertion Outcome based on the response from the downstream endpoint:

    Option Description
    Fail if target returns error status (>=400)

    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.

    Pass through SOAP faults with error status 500

    When failing on an error status, you can give special attention to error status 500 (internal error).

    • Select this check box to allow a status 500 error to be returned from the back-end server as a response, complete with the 500 HTTP error code.
    • Clear this check box to treat the 500 error as a SOAP fault, which may trigger a customized fault response.
    Never fail as long as target returns an answer

    The assertion will succeed if the endpoint returns any response read from the target. With this option, the assertion can fail only if it is not possible to read a response from the target.

    Exception: The assertion may still fail if both of the following conditions are true:

    • In the [Authentication] tab, the Service Authentication is "Use HTTP Credentials from Request".
    • The back-end services returns a 401 HTTP error.

    To prevent assertion failure in this scenario, use "Specify HTTP Credentials" as the Service Authentication method instead. Specify the username and password as context variables from the request (i.e., ${request.username}, ${request.password}).

Was this helpful?

Please log in to post comments.

  1. Lee Barber
    2018-12-18 12:01

    Can someone tell me what this message means: { "statusCode": 500, "errorCode": 5004, "errorMessage": "java.lang.RuntimeException: Unable to use data source Cannot create PoolableConnectionFactory (An existing connection was forcibly closed by the remote host ClientConnectionId:7c2042e2-f26f-47ca-9d3c-49e954c3477d)", "helpUrl": null }

    1. Vincent Cheng
      2018-12-27 06:06

      Thanks for reaching out to us Lee. Please forward this error inquiry to our support folks here for further assistance.