Troubleshooting HTTP Connector - Mule 4

To troubleshoot Anypoint Connector for HTTP (HTTP Connector), enable wire logging and TLS debugging, ensure proper use of the Host header and HTTP encoding, and become familiar with commonly thrown messages.

Enable Wire Logging

Troubleshoot application performance by enabling wire logging, which logs the actual raw HTTP requests and responses in the app workflow. Then use the logs to validate the current configuration or to compare HTTP Connector behavior to that of other clients and servers.

To enable HTTP wire logging:

Access Anypoint Studio and navigate to the Package Explorer view.
Open your application’s project.
Open the src/main/resources path folder.
Open the log4j2.xml file inside the folder.

If the following line is already in the log4j2.xml file, uncomment it to enable it; otherwise, add it:

<?xml version="1.0" encoding="utf-8"?>
<Configuration>
    ...
    <Loggers>
        ...
        <!-- Http Logger shows wire traffic on DEBUG. -->
        <AsyncLogger name="org.mule.service.http.impl.service.HttpMessageLogger" level="DEBUG"/>
        ...
    </Loggers>
</Configuration>

Save your changes.
Click the project name in Package Explorer and then click Run > Run As > Mule Application.

Enable TLS Debugging

Troubleshoot SSL failures by enabling TLS debugging, which logs SSL-related data such as connection attempts, handshakes, and negotiations.

Then use the logs to determine whether the correct certificates are in place, why a cipher or protocol mismatch occurs, or why connectivity fails.

To enable TLS debugging, configure the following system property: -Djavax.net.debug=ssl.

Troubleshoot Host Header Misuse

HTTP clients use the Host header to indicate the host and port number of the resource requested. The HTTP Connector Request operation autogenerates this mandatory header considering the configured host and port. However, servers often consider the port information optional and fail if they receive a request containing it.

Report such failures to the server owner to correct. Meanwhile, work around the issue by manually modifying the Request operation to output a Host header without the port information.

The following example shows a <http:headers> configuration that sends a Host: somehost.com header:

<flow name="connectingToFaultyServer">
  <http:request method="GET" url="http://somehost.com:8081/api/v3/someresource">
    <http:headers>
      #[{"Host" : "somehost.com"}]
    </http:headers>
  </http:request>
  <logger level="INFO"
   message="#['Received a ' ++ attributes.status code ++ ' response with body: {' ++ payload ++ '}']"/>
</flow>

Without the explicit header configuration, an autogenerated Host: somehost.com:8081 would be sent.

Troubleshoot HTTP Encoding

To obtain better performance when working with streamed data, HTTP Connector sends requests and responses with the Transfer-Encoding: chunked encoding when the size of the data being sent is unknown. However, some HTTP clients and servers are not prepared to receive such data and fail.

Report such failures to the server or client owner to correct. Meanwhile, work around the issue by manually modifying the Listener and Request operations to output Content-Length encoded bodies.

The following example shows the HTTP Listener operation configured with responseStreamingMode NEVER, which indicates to use Content-Length encoding:

<flow name="main-contact-read">
  <http:listener path="account/{accountId}/main-contact" allowedMethods="GET" responseStreamingMode="NEVER" config-ref="HTTP_Listener_config"/>
  <!-- fetch main contact for accountId -->
</flow>

The following example shows an HTTP Requester operation configured with requestStreamingMode NEVER to use Content-Length encoding:

<flow name="connectingToFaultyServer">
  <http:request method="GET" url="http://somehost.com:8081/api/v3/someresource" requestStreamingMode="NEVER"/>
  <logger level="INFO"
   message="#['Received a ' ++ attributes.status code ++ ' response with body: {' ++ payload ++ '}']"/>
</flow>

Understand Common Throws

Here is a list of common throw messages and how to interpret them:

HTTP:BAD_REQUEST

The server cannot understand the request due to invalid syntax, for example, when a header size exceeds the maximum.

HTTP:CLIENT_SECURITY

A security problem enforced by an external entity occurred.

HTTP:CONNECTIVITY

A problem occurred and a connection could not be established.

HTTP:FORBIDDEN

The server refuses to give the requested resource because the client does not have access rights to the content.

HTTP:INTERNAL_SERVER_ERROR

The server encountered a situation that prevented it from fulfilling the request.

HTTP:METHOD_NOT_ALLOWED

The server request method is not supported by the target resource.

HTTP:NOT_ACCEPTABLE

The server cannot produce a response matching the list of acceptable values defined in the request's proactive content negotiation headers.

HTTP:NOT_FOUND

The server could not find the requested resource.

HTTP:PARSING

[DEPRECATED but kept for compatibility.] The parsing mechanism has been removed.

HTTP:RETRY_EXHAUSTED

The maximum number of retries for the operation is reached.

HTTP:SECURITY
```
The requester authentication failed.
```

HTTP:SERVICE_UNAVAILABLE

The server is unable to manage the request because it is down for maintenance or overloaded.

HTTP:TIMEOUT

The request sent by an http:requester timed out.

HTTP:TOO_MANY_REQUESTS

Too many request were sent in a given amount of time.

HTTP:UNAUTHORIZED

Authentication failed or has not yet been provided to get the requested response.

HTTP:UNSUPPORTED_MEDIA_TYPE

The server does not support the media format of the requested data.

HTTP:BAD_GATEWAY

The server acting as a gateway or proxy to manage the request received an invalid response.

HTTP:GATEWAY_TIMEOUT

The server acting as a gateway or proxy to manage the request did not receive a response within the specified time.

HTTP:BASIC_AUTHENTICATION

Either the HTTP *Request* operation lacks basic authentication to send requests to the service, or the provided credentials are incorrect.