Contact Us 1-800-596-4880
  1. Homepage

  2. HTTP Connector (0.3.9)

All Connectors

HTTP Connector

The HTTP connector sends and receives HTTP or HTTPS requests using a host, port, and address. With the HTTP connector, you can execute a Mule flow from a URL sent from a browser or a command such as curl. The HTTP connector listens at the host URL and port you specify and then triggers an HTTP response. Alternatively, you can add the HTTP connector elsewhere in your Mule flow to send requests to an address.

Uses for the HTTP connector are to:

  • Listen for Requests - Start your Mule flow with an HTTP Listener Connector to listen for requests that arrive at a host URL and port address. The listener generates an HTTP response.

  • Send Requests - Use the HTTP connector as an HTTP Request Connector to send requests to an address and receive the returned response.

With additional configuration, you can provide:

  • HTTPS - Send or receive HTTPS requests using TLS encryption.

  • Authentication - Send authenticated requests, using basic authentication, digest, and OAuth. Basic uses username and password, Digest encrypts credentials, and OAuth requires an authentication server.

HTTP connector in Mule 3.6 and later

As of Mule 3.6 and newer, the HTTP and HTTPS endpoint-based connectors and transports have been replaced by a single HTTP operation-based connector that supports HTTPS.

Studio Visual Editor

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

HTTP Listener Quick Reference for Studio Users

To add an HTTP listener connector, place it onto a blank Studio canvas into the Source section of a new flow (that is, as the first element in the flow) as you design your Mule application:

New Flow Showing Source and Process Phases:

source flow new blank

Drag the HTTP connector to the source side:

http connector drag to source

The connector populates the source side:

http connector 67263

HTTP Requester Quick Reference

To instantiate 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):

Drag the HTTP connector to the Process side:

http connector drag to process

Flow showing HTTP connector in Process side:

http connector c3457

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 instantiate 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 instantiate 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 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 runtime 3.6, but it’s deprecated and will eventually be removed.
You can edit the log4j2 configuration file to make logging of the HTTP connector’s activity more verbose, if you need to. See Logging in Mule for instructions.

Debugging

Gaining 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 displays metadata of the inbound request:

DEBUG 2019-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: */*

The log output also displays 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 2019 18:55:03 GMT

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

Request Log Output

The log output of the Request displays metadata of the outbound request:

DEBUG 2019-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: */*

The log output also displays information about the response sent back from the target:

DEBUG 2019-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 2019 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 2019-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 2019-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 2019 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 is 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, set this as a property in the <flow> element that contains the HTTP connector.

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

See Also

Back to top
View on GitHub