Differences in CloudHub2.0 Ingress Behavior for India Cloud

CloudHub2.0 Ingress Behavior that are applicable to Mulesoft’s India Cloud only

Who is this applicable to?

If you are an existing Mulesoft customer and bringing Mule applications on CloudHub2.0 from other runtime plane regions, then you may run into scenarios where the Ingress behavior differs between India and other regions. While there are no feature parity gaps, there are some differences between the Ingress controller used in India region compared to other regions. 

What are the differences?

Headers Handling:

There are some differences in how the Ingress controller handles HTTP headers. 

1. x-forwarded-host header: Ingress passes the client's original Host header directly to your backend completely unaltered. This is unlike the behavior in other regions, where the original host is stripped and a x-forwarded-host header is added.  Because the original host is now preserved in the standard header, the x-forwarded-host header is redundant and will be removed.

Action Required: If your application currently relies on x-forwarded-host, please update your application to read the standard Host header.

2. X-correlation-id:Unlike other regions, where Ingress automatically generates the correlation ID if none is provided by the client, for the India region, Ingress does not generate correlation ID in the x-correlation-id header. 

Action Required:  Validate if you relied on the Ingress generated correlation ID for tracing purposes. 

3. X-ssl-client-serial header: This header is used to pass the client’s SSL certificate serial number to your backend for verification. 

While other regions inject this serial number as a decimal value, for India region, the header is injected as a hexadecimal string. Hexadecimal is becoming the industry standard for cryptography as the certificate serial numbers are becoming exceptionally large. Hexadecimal safely preserves the exact bit pattern as a string and directly matches the value shown in standard certificate inspection tools (like OpenSSL), making debugging much easier.

Action Required: If your application parses or validates this header for client authentication, please update your backend logic to expect and decode a hexadecimal format instead of a standard base-10 integer.

 Path Rewriting Behavior:

CloudHub2.0 Ingress supports path rewrite capability. This allows you to decouple public-facing URLs from internal API routing structures. For example, your external URL can be www.example.com/v1/users that points to an application listening on/users endpoint.  

The following table is to guide you how to define the path rewrites for India region applications.