The HTTP transport provides support for exposing services over HTTP and making HTTP client requests from Mule services to external services as part of service event flows. Mule supports inbound, outbound, and polling HTTP endpooints. These endpoints support all common features of the HTTP spec, such as ETag processing, cookies, and keepalive. Both HTTP 1.0 and 1.1 are supported.
HTTP
HTTP Transport
Allows Mule to communicate over HTTP. All parts of the HTTP spec are covered by Mule, so you can expect ETags to be honored as well as keep alive semantics and cookies.
Allows Mule to poll an external HTTP server and generate events from the result. This is useful for pull-only web services.
The cookie specification to be used by this connector when cookies are enabled.
The proxy host name or address.
The password to use for proxy access.
The proxy port number.
The username to use for proxy access.
Whether to support cookies.
The time in milliseconds to wait between each request to the remote HTTP server.
Whether the ETag header from the remote server is processed if the header is present.
Whether Mule should discard any messages from the remote server that have a zero content length. For many services a zero length would mean there was no data to return. If the remote HTTP server does return content to say that that the request is empty, users can configure a content filter on the endpoint to filter these messages out.
Built-in RestServiceWrapper can be used to proxy REST style services as local Mule components.
An error filter can be used to detect whether the response from the remote service resulted in an error.
If the payload of the message is to be attached as a URL parameter, this should be set to the parameter name. If the message payload is an array of objects that multiple parameters can be set to, use each element in the array.
These are parameters that must be available on the current message for the request to be successful. The Key maps to the parameter name, the value can be any one of the valid expressions supported by Mule.
These are parameters that if they are on the current message will be added to the request, otherwise they will be ignored. The Key maps to the parameter name, the value can be any one of the valid expressions supported by Mule.
The HTTP method to use when making the service request.
The service URL to use when making the request. This should not contain any parameters, since these should be configured on the component. The service URL can contain Mule expressions, so the URL can be dynamic for each message request.
A transformer that converts an HTTP response to a Mule Message. The payload may be a String, stream, or byte array.
Converts an HTTP response payload into a string. The headers of the response will be preserved on the message.
This transformer will create a valid HTTP request using the current message and any HTTP headers set on the current message.
This transformer will create a valid HTTP response using the current message and any HTTP headers set on the current message.
This transformer parses the body of a HTTP request into a Map.
An inbound HTTP endpoint exposes a service over HTTP, essentially making it an HTTP server. If polling of a remote HTTP service is required, this endpoint should be configured with a polling HTTP connector.
The HTTP outbound endpoint allows Mule to send requests to external servers or Mule inbound HTTP endpoints using the HTTP protocol.
If a request if made using GET that responds with a redirectLocation header, setting this to true will
make the request on the redirect URL. This only works when using GET since you cannot automatically follow
redirects when perfroming a POST (a restriction according to RFC 2616).
Configures a 'global' HTTP endpoint that can be referenced by services. Services can augment the configuration defined in the global endpoint with local configuration elements.
If a request if made using GET that responds with a redirectLocation header, setting this to true will
make the request on the redirect URL. This only works when using GET since you cannot automatically follow
redirects when perfroming a POST (a restriction according to RFC 2616).
The user name (if any) that will be used to authenticate against.
The password for the user.
The host to connect to. For inbound endpoints, this should be an address of a local network interface.
The port number to use when a connection is made.
The path for the HTTP URL.
The HTTP ContentType to use.
The HTTP method to use.
Controls if the socket connection is kept alive. If set to true,
a keep-alive header with the connection timeout specified in the connector will be
returned. If set to false, a "Connection: close" header will be returned.
(As of 2.2.2) The request-wildcard-filter element can be used to restrict the request by applying wildcard expressions to the URL.