Odd behavior migrating to http:listener in Mule 3.8

Question

After migrating our Mule application to using the new http:listener, I found unexpected behavior. If a client sends an HTTP POST without including a Content-Type header, the http:listener will bookend the payload with curly braces before delivering the payload for processing.

Client sends: < [valid xml string >

Received payload: {< [valid xml string] >}

Is this behavior expected? If so, what is the rational?

Thanks, Steve

Answer 1

Best Answer

May 16, 2018 at 01:44 PM, mulsoft answered with:

Hi @sjcurt01 ,

Yes Its correct behavior because All transport layer components like http,vm and all they returned Objects and here {} shows its a object.

Thanks and Regards,

Manish Yadav

Add comment

10 |1200 characters needed characters left characters exceeded

Answer 2

Doing some more research, I found the answer to the question I was looking for. My frustration was in the http:listener component's modification of the payload from the original value as sent by the client. As our Mule instance acts more as a proxy and does not process the payload, the modification of the payload content was unexpected, and different than the previous Mule 3.6 http:connector behavior. The behavior I wanted came with configuring the http:listener component with the parseRequest="false" attribute. In doing so, the listener isn't responsible for trying to figure out what kind of payload is being passed, and leaves the payload unaltered regardless of what or if a content-type header is included in the request or not. This behavior matches more closely the behavior of the previous http:connector component.

@mulsoft , Thanks for the explanation, though. It makes sense in the context of wanting the http:listener to parse and interpret the payload for you.

Thanks, Steven Curtis

Odd behavior migrating to http:listener in Mule 3.8

2 Replies

Your answer

Like this question?

Who's following the question

Related Questions