--- schema_version: "1" id: 05f58a1e790d41d96ad1c82046b7cf324986562977068dde7a24e6831b41ce8c title: Migrating HTTP Connector Uses collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/mule-runtime/4.3/migration-connectors-http.md canonical_url: https://docs.mulesoft.com/mule-runtime/4.3/migration-connectors-http source_site: docs.mulesoft.com content_type: documentation content_hash: 978b3137b02e033b222db3e27e1633d9d9cd5d90a85ca00bfa24a9be0f86179e description: MuleSoft Documentation Site release: "4.3" latest: false --- --- product: Mule Runtime version: 4.3 --- # Migrating HTTP Connector Uses > For the full documentation index, see: https://docs.mulesoft.com/llms.txt For the most part, the HTTP connector has just been adapted to the Mule 4 model: - Configuration properties have been moved to a connection component when applicable. - Message processors have been refactored into proper operations. - Outbound properties such as `http.status` have been removed in favor of explicit properties. - Inbound properties such as `http.queryParams` have been removed in favor of HTTP specific message attributes. - Threading configuration has been removed since it’s now all handled at the Mule Runtime level. - Special handling for `application/x-www-form-urlencoded` and `multipart/*` media types has been removed in favor of DataWeave. - RAML metadata support has been removed from the HTTP request operation in favor of REST Connect. ## What’s Covered Here? - [HTTP Listener](#http_listener) - [HTTP Request](#http-request) - [HTTP Static Resource Handler](#http-static-resource) - [HTTP Basic Security Filter](#http-basic-authentication) - [HTTP MIME Type Parsing](#http-mime-types) ## HTTP Listener The HTTP Listener has only seen major changes in the configuration of its response builders, as well as the encapsulation of its configuration properties into a specific connection component. ### Configuration The following properties and components must now be defined within an inner `http:listener-connection` component: - `host` - `port` - `protocol` - `usePersistentConnections` - `connectionIdleTimeout` - TLS Context Mule 3 example ```xml ``` Mule 4 example ```xml ``` ### Listener All HTTP Listener properties remain the same except for the `http:response-builder` and `http:error-response-builder`. These have been renamed to simply `http:response` and `http:error-response`, and now require the headers to be defined through a single expression while removing support for implicit outbound properties handling. Additionally, they support a new `http:body` component where an expression can be used to define the outgoing HTTP message body. Mule 3 example In the following example, a number of `User-Agent` headers are sent in a response set up through an implicit outbound property (`Mule 3.6.0`), a single header reference (`Mule 3.7.0`) and an expression reference (`Mule 3.8.0` and `Mule 3.9.0`). An error response, on the other hand, will feature a `Date` header as well as the outbound property for `User-Agent`. ```xml ... ``` Mule 4 example Notice that while `statusCode` and `reasonPhrase` properties remain the same, all headers should now be explicitly added using a DataWeave expression. It’s important to note that explicit `statusCode` and `reasonPhrase` must be provided as well to replace usages of outbound properties `http.status` and `http.reason`. ```xml #[{ 'User-Agent' : 'Mule 3.6.0', 'User-Agent' : 'Mule 3.7.0', 'User-Agent' : 'Mule 3.8.0', 'User-Agent' : 'Mule 3.9.0' }] #[{ 'User-Agent': 'Mule 3.6.0', 'Date': now() }] ... ``` #### Attributes Following the new Mule Message structure, the HTTP listener now provides all request metadata through specific HTTP Request Attributes. Below you can find the new ways of accessing that metadata compared to Mule 3.
MetadataMule 3Mule 4

Method

#[inboundProperties.'http.method']

#[attributes.method]

Path

#[inboundProperties.'http.listener.path']

#[attributes.listenerPath]

Relative Path

#[inboundProperties.'http.relative.path']

#[attributes.relativePath]

Request URI

#[inboundProperties.'http.request.uri']

#[attributes.requestUri]

Query String

#[inboundProperties.'http.query.string']

#[attributes.queryString]

Query Parameters

#[inboundProperties.'http.query.params']

#[attributes.queryParams]

URI Parameters

#[inboundProperties.'http.uri.params']

#[attributes.uriParams]

Version

#[inboundProperties.'http.version']

#[attributes.version]

Scheme

#[inboundProperties.'http.scheme']

#[attributes.scheme]

Headers

#[inboundProperties]

#[attributes.headers]

Remote Address

#[inboundProperties.'http.remote.address']

#[attributes.remoteAddress]

Client Certificate

#[inboundProperties.'http.client.cert']

#[attributes.clientCertificate]

Notice that while the HTTP headers were mapped directly into inbound properties, now they have an exclusive object. Below you can find an example of how to obtain a header: - Mule 3: `#[inboundProperties.'host']` - Mule 4: `#[attributes.headers.'host']` #### Encode Characters for HTTP Requests In Mule 4 to avoid a malformed URI when you make an HTTP request to the HTTP Listener, encode characters such as `{` and `}` that you set in the HTTP request as recommended in [RFC](https://datatracker.ietf.org/doc/html/rfc1738). Encode these characters both when you configure the request URL in the **Path** field of the HTTP Listener in Studio, and when you send the curl request command. In the following example, you encode the characters `{` to `%7B` and `}` to `%7D` of the URL `path=/profiles/{profileid}/credit`: 1. In Studio, select the HTTP **Listener** source from your flow. 2. In the **Path** field, set the relative path URL with the encoded characters, for example, `/profiles/%7Bprofileid%7D/credit` 3. Save all your application changes in Studio. 4. Run the curl command `http://localhost:8084/test?path=/profiles/%7Bprofileid%7D/credit` ## HTTP Request Like the HTTP listener, most changes in the HTTP request operation regard the encapsulation of configuration properties within a connection component and the request building process. ### Configuration The following properties and components must now be defined within an inner `http:request-connection` component: - `host` - `port` - `protocol` - `usePersistentConnections` - `maxConnections` - `connectionIdleTimeout` - `streamResponse` - `responseBufferSize` - HTTP Authentication - HTTP Proxy - TLS Context - TCP Client Socket Properties Mule 3 example ```xml ``` Mule 4 example ```xml ``` Note that RAML metadata support has been removed because REST Connect can now generate a specific connector for a given RAML, which can then be reused. #### HTTP Authentication In addition to now belonging in the `http:request-connection` component, the HTTP authentication configuration must be placed within an `http:authentication` component. This applies to all authentication types supported: basic, digest, NTLM and OAuth2. Mule 3 example ```xml ``` Mule 4 example ```xml ``` #### HTTP Proxy Just like the HTTP Authentication component, configuring an HTTP proxy now requires a wrapping `http:proxy-config` component, for all kinds of proxies. Mule 3 example ```xml ``` Mule 4 example ```xml ``` #### TCP Client Socket Properties In Mule 3, TCP client socket properties were defined based in the TCP transport which has been replaced in Mule 4 by the Sockets Connector, so now that is required to configure the properties. Additionally, the properties must be wrapped in an `http:client-socket-properties` component. Mule 3 example ```xml ``` Mule 4 example ```xml ``` ### Request All HTTP request properties remain the same except for the `source` which has between replaced by an `http:body` component supporting expressions and transformations and the `http:request-builder` which has been removed. Headers, query and URI parameters should now be defined explicitly through DataWeave expressions. Mule 3 example ```xml ... ... ``` Mule 4 example ```xml ... #[vars.customSource] #[{ 'Host': 'www.example.com' 'Transfer-Encoding' : 'chunked' }] #[{ 'id' : vars.songId }] #[vars.params] ... ``` #### Attributes Like the HTTP Listener , the HTTP request now provides all response metadata through specific HTTP Response Attributes. Below you can find the new ways of accessing that metadata compared to Mule 3.
MetadataMule 3Mule 4

Status Code

#[inboundProperties.'http.status']

#[attributes.statusCode]

Reason Phrase

#[inboundProperties.'http.reason']

#[attributes.reasonPhrase]

Headers

#[inboundProperties]

#[attributes.headers]

Notice that headers are treated just like in the HTTP Listener. ## HTTP Static Resource Handler The HTTP Static Resource Handler has been adapted to Mule 4’s operation model and renamed to `http:load-static-resource`. The `resourceBase` property has also been renamed to `resourceBasePath`. Mule 3 example ```xml ``` Mule 4 example ```xml ``` Though this operation is only meant to be used with an HTTP Listener source, we’ve also introduced an `attributes` property where you can reference the HTTP request attributes of the listener and thus use the operation in any point of the flow. ## HTTP Basic Security Filter The HTTP Basic Security Filter has not been changed except to support DataWeave as a source for the `securityProviders` property and the introduction of an `attributes` property where you can reference the HTTP request attributes of the listener and thus use the operation in any point of the flow, just like the HTTP load static resource operation. Mule 3 example ```xml ``` Mule 4 example ```xml ``` See [Configure LDAP Provider for Spring Security](https://docs.mulesoft.com/mule-runtime/4.3/setting-up-ldap-provider-for-spring-security) for a complete configuration example. ## HTTP MIME Type Parsing The HTTP connector in Mule 3 featured options to parse requests and responses when bodies of type `application/x-www-form-urlencoded` or `multipart/form-data` (and other subtypes) were received. When the parsed objects where encountered on outbound requests and responses, they were transformed back into those types of bodies for consistency. However, since DataWeave 2.0 now handles those MIME types, in Mule 4 HTTP parsing has been removed and HTTP components always provide and require binary data streams. Below you can find details on how to migrate uses of the formerly parsed types. ### application/x-www-form-urlencoded In Mule 3, a `Map` payload was used as a counterpart of `application/x-www-form-urlencoded` content. For outbound traffic, that meant that if a `Map` payload was present, then each key-value pair would be used to generate an `application/x-www-form-urlencoded` body. For inbound traffic, it meant that each key-value pair of that body would be put in a `Map`. Now, DataWeave can read and write `application/x-www-form-urlencoded` content, making it easier and more consistent to work with different MIME types in HTTP. Mule 3 example In this example, a payload of `song=Snow+Poems&artist=TQP` is sent and returned featuring an ID with which it was saved: `song=Snow+Poems&artist=TQP&id=49`. ```xml ``` Mule 4 example Notice that the syntax for reading the content remains the same except that now we must indicate an output type since we are actually transforming data. ```xml ... #[ %dw 2.0 output application/x-www-form-urlencoded --- { song: "Snow Poems", artist: "TQP" }] ... ``` Several values for a key can be added, just keep in mind accessing that data requires using the star selector to get the collection of all associated values: `#[payload.*artist]` would return a list with `David Bowie` and `Queen` for the song `Under Pressure`, for example. ### multipart/\* Mule Message attachments were used in Mule 3 as a counterpart of multipart content. For outbound traffic that meant that if attachments were present then those would be use as parts of a `multipart/form-data` body. For inbound traffic it meant that each part of that body would be mapped to a Mule Message attachment. In Mule 4, Mule Message attachments no longer exist. Instead, you can read and write multipart content through DataWeave as you would with JSON or XML content. Mule 3 example In this example, a `multipart/form-data` body is received featuring 2 JSON parts, an order and a partner who has generated it. After logging the partner name, the order ID is saved to generate a `multipart/form-data` response featuring a simple message acknowledging the order and a PDF receipt generated for it. ```xml ``` Mule 4 example All the complexity of handling the attachments is now gone, and we just access the parts by name using the `content` keyword. The multipart response is generated in the HTTP response body using DataWeave, where you can easily customize headers. ```xml ``` It’s important to notice that while we are taking advantage of the `http:body` feature, the same result could be achieved using a final transform component. Note that the boundary is autogenerated, which results in a correct content-type header. For details, see [Multipart Format (Form-Data)](https://docs.mulesoft.com/dataweave/2.3/dataweave-formats-multipart). == See Also [Core Components Migration](https://docs.mulesoft.com/mule-runtime/4.3/migration-core) [REST Connect](https://docs.mulesoft.com/exchange/to-deploy-using-rest-connect)