Removed HTTP Headers in WSO2 MI… But a Hidden Cookie Broke Everything

Why your “clean” request might still be carrying invisible baggage.

If you have worked with WSO2 Micro Integrator for some time, you’ve probably had a moment where everything looks right… but the system still fails in the most confusing way possible.

Well, this is one of those stories.

Everything started with a simple assumption: “If I remove HTTP headers, nothing unnecessary gets passed down.”

But it turns out that assumption isn’t always true.

The Scenario

I had a straightforward integration flow:

The task was to implement a new backend call to the existing integration flow. In this integration flow, the previous call’s response contained multiple headers and due to this, before the new backend call, the headers were removed using the below property:

<property name="TRANSPORT_HEADERS" action="remove" scope="axis2"/>

At this point everything looked correct. The request going into the Backend should have been clean.

The Unexpected Failure

During testing, the newly created endpoint failed with:

405 Method Not Allowed

This was not a random failure:

• The payload was verified and it was correct.
• Endpoint returned success response in standalone call.
• The headers were supposedly removed.

Yet, the issue persisted.

Digging Deeper

If everything looks fine but something doesn’t make sense in WSO2 MI, my lead always used to say: “Enable wire logs.”

That’s when I noticed something unexpected:

Cookies from a previous backend call response were sent to the newly implemented backend call.

Even though I had already explicitly removed transport headers.

The Hidden Behavior

So, here’s the catch:

WSO2 Micro Integrator doesn’t treat cookies exactly like regular headers. Some headers can be stored outside the standard TRANSPORT_HEADERS, so removing them doesn’t always clear everything.

As a result of this, a cookie can still be moved forward even when the request appears clean which could lead to unexpected backend behaviors.

The Fix

After some digging, I came across a lesser-known property:

<property name="EXCESS_TRANSPORT_HEADERS" action="remove" scope="axis2"/>

Adding this property ensured that all the unnecessary transport-level data was removed including the cookies.

And just like that,

• The issue disappeared
• Backend call for the new endpoint started responding correctly
• The flow worked as expected

What This Teaches Us

The issue highlights a subtle but a very important behavior in WSO2 Micro Integrator.

1. Not all headers are equal
2. Cookies can be “invisible troublemakers”
3. Always validate with wire logs

Final Thoughts

In integration related work, the biggest problems are often ones you don’t see.

This experience was a good reminder:

A request that looks clean isn’t always clean.

So next time when stripping headers in WSO2 MI, make sure you’re not leaving behind a silent cookie that breaks everything.

References:

• Yenlo Blog: Preventing HTTP Headers in WSO2 EI — https://www.yenlo.com/blogs/wso2ei-preventing-http-headers-responses/
• How to remove http header from Response in WSO2 ESB — https://stackoverflow.com/questions/27859592/how-to-remove-http-header-from-response-in-wso2-esb

Hope you enjoyed the blog and got something to take away.

Thank you for Reading! Cheers!!!