To support the continued reliability, scalability, and security of your Mule applications as your business grows, MuleSoft is executing an infrastructure upgrade to the MuleSoft GovCloud load balancers. As part of this upgrade, the format used to deliver certain HTTP response bodies to your applications is changing.
While both the previous and new formats are compliant with the HTTP/1.1 standard and are handled transparently by most modern HTTP clients, you may need to review your integration code depending on how your applications read HTTP responses.
Effective Date: 21st Sept 2026
When your CloudHub application returns a response, the Mule HTTP Listener determines how the response body is framed on the wire.
Previously, the GovCloud load balancer internally buffered chunked responses and re-framed them with a Content-Length header before delivery. Following this upgrade, the load balancer will operate as a transparent passthrough, allowing chunked responses to reach your client directly.
|
Before |
After | |
|
Fixed-size payloads |
Content-Length: <N> |
Content-Length: <N> (unchanged) |
|
DataWeave / streamed / large payloads |
Content-Length: <N> (re-framed by load balancer) |
Transfer-Encoding: chunked |
The action required depends on your current application and code configuration:
If your application uses standard HTTP client libraries: If your code reads response bodies through standard library APIs (e.g., Java's HttpClient, Python's requests, Node.js axios, .NET HttpClient, or standard web browsers via response.json(), response.getBody(), response.body()), no action is required. These libraries handle both formats transparently.
If your application relies on specific header logic: You must review and update your integration code prior to the effective date if any of the following apply:
Your code explicitly reads or parses the Content-Length response header.
Your code pre-allocates a buffer using Content-Length before reading a response.
Your code uses Content-Length to determine when to terminate a streaming loop.
You utilize a custom, hand-rolled HTTP parser instead of a standard library.
An intermediate HTTP proxy (e.g., Nginx, HAProxy, or an internal API gateway) is in front of your application and assumes Content-Length is always present.
Following the upgrade deadline, applications that rely strictly on the presence of the Content-Length header for dynamically generated or streamed payloads will experience integration failures, such as NullPointerExceptions, KeyErrors, truncated data parsing, or blocked traffic.
Important Testing Note: You must test multiple endpoints. The new framing only applies to dynamically generated responses (DataWeave-transformed or streamed bodies). Testing only a single fixed-payload endpoint may give a false impression that no change occurred.
To validate your endpoints, run the following command against your integration targets:
curl -isk https://<your-app>.usg-w1.gov.cloudhub.io/<your-endpoint> | head -20
HTTP/1.1 200 OK
Server: nginx
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
{ "your": "response body" }
HTTP/1.1 200 OK
Server: nginx
Content-Type: application/json
Content-Length: 27
Connection: keep-alive
{ "your": "response body" }
Endpoints that return fixed-size payloads will continue to include Content-Length. This is expected and confirms there is no change for that specific endpoint. Make sure to test endpoints with dynamically generated responses to verify the new framing.
If your validation surfaces issues, look for the following patterns in your codebase and refactor them to use standard body-reading APIs:
// Old Pattern (Will cause NullPointerException/Errors)
String cl = response.getHeader("Content-Length");
long size = Long.parseLong(cl);
// Recommended Refactor
String body = EntityUtils.toString(response.getEntity());
# Old Pattern (Will cause KeyError)
size = int(response.headers["Content-Length"])
# Recommended Refactor
data = response.json()
// Old Pattern (Will return null)
const total = response.headers.get("content-length");
// Recommended Refactor
const data = await response.json();
005387415

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.