Troubleshooting HTTP Connector | MuleSoft Documentation
# Troubleshooting HTTP Connector
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:
  1. Access Anypoint Studio and navigate to the **Package Explorer** view.
  2. Open your application’s project.
  3. Open the `src/main/resources` path folder.
  4. Open the `log4j2.xml` file inside the folder.
  5. 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>
```



  6. Save your changes.
  7. 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>
```

## Troubleshoot OAuth2 Authorization Code Grant Type Issues
If your Mule app uses OAuth2 Authorization Code Grant Type authentication and returns the `_No access token found. Verify that you have authenticated before trying to execute an operation to the API_`message, check these possible solutions:
  * Call Authorization URL: As per the OAuth policy, it is necessary to call the authorization URL at least once to obtain the access token.
  * Use an Object Store: Save the access token in an Object Store. If the token expires, retrieve a new access token using the refresh token and update the Object Store.
  * Use DocuSign Connector: Consider using DocuSign Connector to manage authentication and token management more effectively.


## 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
  * HTTP Listener Configuration Reference
  * HTTP Request Configuration Reference
  * MuleSoft Help Center
  *