
Questions: 23,729 //
Answers: 52,301 //
Contributing Members: 17,997
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
Jun 14, 2018 at 03:40 PM, sjcurt01 answered with:
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