Loading

HTTP Connector | mule.http.client.decompress system property is not working

Publiceringsdatum: Jul 25, 2025
Lösning

SYMPTOM

You have specified the system property -Dmule.http.client.decompress=true in your Mule application to automatically decompress response payloads but find that it is not working. 

CAUSE

This property only supports GZIP encoding and your response payload may use another encoding, such as Brotli. To check the encoding of the payload, enable HTTP Wire logging in your application.
You will see debug logger containing the response from the remote endpoint:
  
DEBUG 2024-02-27 16:52:56,104 [[xxx].http.requester.HTTPS_Request_config.01 SelectorRunner] [processor: main/processors/1/route/0/processors/0; event: xxxxxx] org.mule.service.http.impl.service.HttpMessageLogger.http.requester.HTTPS_Request_config: REQUESTER
HTTP/1.1 200 OK
Date: Tue, 27 Feb 2024 15:52:56 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Content-Encoding: br
Vary: Accept-Encoding

In this example, the server returned the response payload using Brotli encoding. As this is not supported by the 'mule.http.client.decompress' property, the payload will not be decompressed.

SOLUTION
You can request that the remote endpoint returns the response payload using GZIP encoding so the property will work correctly. This can be done by forcing the Accept-Encoding request header:
  
Accept-encoding: gzip
Knowledge-artikelnummer

001117234

 
Laddar
Salesforce Help | Article