Contact Free trial Login
All Connectors

HTTP Connector Troubleshooting Guide

Wire Logging

The best way to troubleshoot HTTP issues is to enable wire logging. When wire logging is set up, the actual raw HTTP requests and response flowing through are logged.

Once logs are collected, they can be used to validate the current configuration or to compare the HTTP connector behavior to other clients and servers.

To enable HTTP wire logging, the following entry should be added to your artifact’s log configuration (log4j2.xml):

<?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>

TLS Debug

When SSL failures are seen or suspected because HTTPS is being used, usually connections cannot even be established and wire logging is not helpful. In this situations, SSL debug should be enabled which will log all SSL related data, such as connection attempts, handshakes, negotiations and so on.

Logs can then be examined to determine whether the correct certificates are in place, a cipher or protocol mismatch is occurring or why connectivity is failing.

To enable TLS debugging, the following system property needs to be configured: -Djavax.net.debug=ssl.

Common Issues

These are some of the common issues seen while working with HTTP.

Host Header Misuse

The Host header is used by HTTP clients to indicate the host and port number of the resource being requested. It is a mandatory header which the HTTP request autogenerates considering the configured host and port.

Often, servers do not account for the port information because it’s optional, and fail when receiving a request that has both the host and port data.

Such failures should be reported to the server owners. While a fix is provided, the HTTP request operation can be modified to workaround the issue by providing an explicit Host header without the port section.

For example, the following configuration will send 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.

HTTP Encoding Support

The HTTP connector sends requests and responses with Transfer-Encoding: chunked encoding when there’s no available information about the size of the data to send. This is very common when working with streamed data to obtain better performance.

Occasionally, HTTP clients and servers are not prepared to receive such data and fail.

Such failures should be reported to the server or client owners. While a fix is provided, both the HTTP listener and request can be modified to workaround the issue by always returning Content-Length encoded bodies.

In the following example, an HTTP listener is configured with responseStreamingMode NEVER, which indicates Content-Length encoding should always be used.

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

In this example, an HTTP request operation is configured requestStreamingMode NEVER, which indicates Content-Length encoding should always be used.

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

See Also