Loading

Upcoming change to HTTP response format on MuleSoft GovCloud

Data pubblicazione: Jun 19, 2026
Descrizione

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

How does this affect your applications?

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

 

What action do you need to take?

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.




What happens if you don’t take this action?

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.

 

How to Validate and Refactor

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

 

Expected Output for Dynamic / DataWeave Payloads (The Change):



HTTP/1.1 200 OK

Server: nginx

Content-Type: application/json

Transfer-Encoding: chunked

Connection: keep-alive

 

{ "your": "response body" }

 

Expected Output for Fixed-Size Payloads (No Change):

 

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.

Code Patterns to Review and Refactor:

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();

 

Numero articolo Knowledge

005387415

 
Caricamento
Salesforce Help | Article