Yes, the curl command was not correct, sorry for that. However, the
supplier sends the xml-docs without headers, I can't help it, thats
indeed strange and, therefore, it is a very nice camel feature to plug
in custom http bindings to deal with strange issues like that. With the
DefaultHttpBinding I run into this error, with my custom binding not...
the point is, that I took me some time to realize that it is actually
about the http binding, once I figured that out, it was easy. So the
mailinglist posting may save some time for subsequent programmers.
I don't think a backport is necessary, but a fix in forthcoming releases
would make camel more robust, so a fix in trunk would be nice. I just
downloaded 2.8-SNAPSHOT from the homepage and I cannot see any
difference in the classes in question, so I cannot verify the fix -- or
where do I have to look for it?
On 30.03.2011 03:51, Willem Jiang wrote:
I just did some test on the issue, and found out it was caused by the
request message was not right.
As the Http Request was sending with application/x-www-form-urlencoded,
which means the message body should be some string like
"file.name=file.xml", but with the "curl -v -d file.xml
'http://localhost:4443/to2-service/sendMessage";, the message body became
"file.xml", and DefaultHttpBinding throw the exception like that.
And it has nothing to do with the Null Http header.
I just did a quick fix for in Camel trunk, please check out latest Camel
2.8-SNAPSHOT to verify the fix.
On 3/29/11 3:32 AM, Knut Enners wrote:
Finally, I found the error - thanks for helping anyway ;)
It's a camel bug (2.4., 2.6) affecting the classes
org.apache.camel.component.http.DefaultHttpBinding
org.apache.camel.component.http4.DefaultHttpBinding
method readRequest needs to check null-values, as POST requests may not
set any headers.
