= Troubleshooting HTTP Connector - Mule 4
:keywords: anypoint studio, esb, connectors, http, https, http headers, troubleshooting, rest, raml

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:
+
[source,xml,linenums]
----
<?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>
----

[start=6]
. 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:

[source,xml,linenums]
----
<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:

[source,xml,linenums]
----
<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:

[source,xml,linenums]
----
<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.

== See Also

* xref:http-listener-ref.adoc[HTTP Listener Configuration Reference]
* xref:http-request-ref.adoc[HTTP Request Configuration Reference]