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