Route via HTTP(S) Assertion

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:
gateway92
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.
2
A message routing assertion is an essential policy element. When you publish a service using the  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.
(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.
When routing failures to the backend 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 backend services and allows the Gateway to return an intelligent response to the client that the backend 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 backend 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 will verify 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 is 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
    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.
    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.
  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}".
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.
(1) If no credentials are entered, the authentication option will revert to "None (Anonymous)" the next time the [Authentication] tab is opened. (2) NTLM authentication is not supported when a proxy server is configured (see "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.
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).
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.
(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 "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 will revert 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
These headers are always passed through as is. The message
"Custom rules can't be defined for this header name."
is displayed if you try to add any of these headers to the list, even when using the "Pass original value" option.
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 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 backend 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.
    The cluster property
    io
    .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.
    The cluster property
    io
    .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 fails (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.
        Configure the Connection Timeout proportionally to the distance or latency of your backend services. For backend services on the same physical server or rack, set Connection Timeout several milliseconds greater than the latency to that service. For example, if the backend service has 10ms latency, the Connection Timeout should be approximately 20ms. For backend 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 backend 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 fails (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 backend server. As a result, it is possible that the actual communication time is 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 backend 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 are 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" prevents retries). The default is
      3
      retries.
      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 uses 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
    As with all trusted certificates, the certificates in this list are 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. The other settings 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.
    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.
    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).
    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. Click
    Customize Request Form POST Parameters
    if you need to change how these parameters work. You are 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.
      (1) You may repeat parameter names if you are constructing multiple rules on handling a particular parameter. See " 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
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.
    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.
    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 backend service. In certain cases, this actor may cause the backend service to ignore the Security headers because it believes it is addressed to someone else. You will also use this setting if the backend 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 incurs 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.
    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.
    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 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 fails 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.
    If an error occurs while getting a response from the target, the assertion fails.
    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 backend 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 succeeds 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 backend 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}
    ).