salesforce Dreamforce On-Demand
Contact Us 1-800-596-4880
  1. Homepage

  2. HTTP Connector (0.3.7)

All Connectors

HTTP Connector

Anypoint Connector for HTTP (HTTP Connector) sends and receives HTTP or HTTPS requests using a host, port, and address.

Depending on which type of HTTP connector you use, you can either:

Through additional configuration, the connector allows you to:

  • Use TLS encryption to send or receive HTTPS requests

  • Send Authenticated Requests, through Basic Authentication, Digest and OAuth

Studio Visual Editor

In Studio, the HTTP Connector can work in one of two ways, depending on where it’s placed on a flow:

To instance the connector as an HTTP Listener Connector, you must place it into the Source section of a flow (ie: as the first element in the flow):

add+listener

To instance the connector as an HTTP Request Connector, you must place it into the Process section of a flow (ie: anywhere except the beginning of it):

add+request+connector

XML Editor

When writing Mule projects in XML, the HTTP Connector can work in one of two ways, depending on how you create it:

To instance the connector as an HTTP Listener Connector, add the following XML tag at the start of a flow:

<http:listener config-ref="HTTP_Listener_Configuration" path="/" />

This element must reference a global configuration element of the following type:

<http:listener-config name="HTTP_Listener_Configuration" host="localhost" port="8081" />

To instance the connector as an HTTP Request Connector, add the following XML tag in any part of a flow:

<http:request config-ref="HTTP_Request_Configuration" path="/" method="GET" />

This element must reference a global configuration element of the following type:

<http:request-config name="HTTP_Request_Configuration" host="example.com" port="8081"/>
To migrate a project that uses instances of the old HTTP endpoint-based connector to the new HTTP operation-based connector, see Migrating to the New HTTP Connector. The old HTTP endpoint-based Connector still works with Mule 3.6 Runtime, but it’s deprecated and will eventually be removed.
You can edit the log4j2 configuration file to make the logging of the HTTP connector’s activity a lot more verbose, if you need to. See Logging in Mule for instructions.

Debugging

Gaining greater visibility into HTTP inbound and outbound behavior can be achieved by enabling underlying library loggers with log4j2. This section assumes you’re comfortable adjusting log levels with log4j2. If you have not adjusted logging levels in the past, read configuring custom logging settings before continuing.

Logging Listener and Request Activity

By enabling the DEBUG level on org.mule.module.http.internal.HttpMessageLogger, activity coming from all HTTP Listener and Request components will be logged. This includes the HTTP Listener Connector’s inbound request, HTTP Request Connector’s outbound request, and each connector’s response body. An example of each can be found below.

Listener Log Output

The log output of the Listener will display metadata of the inbound request.

DEBUG 2016-02-10 10:55:03,234 [[hello].HTTP_Listener_Configuration.worker.01] org.mule.module.http.internal.HttpMessageLogger: LISTENER
GET / HTTP/1.1
Host: localhost:8081
User-Agent: curl/7.43.0
Accept: */*

It will also display information about the response being sent back.

LISTENER
HTTP/1.1 200
Transfer-Encoding: chunked
Content-Type: application/json; charset=UTF-8
Date: Wed, 10 Feb 2016 18:55:03 GMT

2000
{
  "message" : "hello, world"
}
Chunked encoding will produce a separate log record for each chunk.

Request Log Output

The log output of the Request will display metadata of the outbound request.

DEBUG 2016-02-10 11:29:18,647 [[hello].http.requester.HTTP_Request_Configuration(1) SelectorRunner] org.mule.module.http.internal.HttpMessageLogger: REQUESTER
GET /v3/hello HTTP/1.1
Host: mocker-server.cloudhub.io:80
User-Agent: AHC/1.0
Connection: keep-alive
Accept: */*

It will also display information about the response sent back from the target.

DEBUG 2016-02-10 11:29:18,729 [[hello].http.requester.HTTP_Request_Configuration.worker(1)] org.mule.module.http.internal.HttpMessageLogger: REQUESTER
HTTP/1.1 200
Content-Type: application/json
Date: Wed, 10 Feb 2016 19:29:18 GMT
Server: nginx
Content-Length: 10940
Connection: keep-alive

{
  "message" : "Hello, world"
}

Logging Packet Metadata

At a lower level, it can be desirable to log the actual request and response packets transmitted over HTTP. This is achieved by enabling the DEBUG level on com.ning.http.client.providers.grizzly. This will log the metadata of the request packets from AsyncHTTPClientFilter and the response packets from AhcEventFilter. Unlike the HttpMessageLogger, this will not log request or response bodies.

Request Log Output

The log output of the request packet’s metadata is as follows.

DEBUG 2016-02-10 11:16:29,421 [[hello].http.requester.HTTP_Request_Configuration(1) SelectorRunner] com.ning.http.client.providers.grizzly.AsyncHttpClientFilter: REQUEST: HttpRequestPacket (
   method=GET
   url=/v3/hello
   query=null
   protocol=HTTP/1.1
   content-length=-1
   headers=[
      Host=mocker-server.cloudhub.io:80
      User-Agent=AHC/1.0
      Connection=keep-alive
      Accept=*/*]
)

Response Log Output

The log output of the response packet’s metadata is as follows.

DEBUG 2016-02-10 11:16:29,508 [[hello].http.requester.HTTP_Request_Configuration.worker(1)] com.ning.http.client.providers.grizzly.AhcEventFilter: RESPONSE: HttpResponsePacket (
  status=200
  reason=
  protocol=HTTP/1.1
  content-length=10940
  committed=false
  headers=[
      content-type=application/json
      date=Wed, 10 Feb 2016 19:16:29 GMT
      server=nginx
      content-length=10940
      connection=keep-alive]
)

Non-blocking Processing

The HTTP Connector (both the HTTP Listener and the HTTP Request connector) can be used with a non-blocking processing strategy. This means that whenever a message is pending a response from an external source, the message processor will still be free to process other messages that keep arriving to it. Read more about this in Non-Blocking Processing Strategy.

To enable the non-blocking processing strategy, you must set this as a property in the '<flow>' element on which the HTTP Connector sits.

Note that not all Mule components currently support the non-blocking processing strategy, if there are any unsupported components in a flow, they will cause the flow to fall back to synchronous processing.

See Also