Even weirder, this only seems to happen on Solaris. If I run my route on Linux, then I get the proper string without the chunked encoding characters.
I found this, which suggests that it might just be a bug in the JDK: http://www-01.ibm.com/support/docview.wss?uid=swg21255293 I'd still like to be able to get my simulated DataPower route to send a chunked response, though. Any ideas on how I can do that? -----Original Message----- From: Sharples, Colin [mailto:colin.sharp...@anz.com] Sent: Tuesday, 12 December 2017 6:00 p.m. To: users@camel.apache.org Subject: netty4-http send chunked response I have a route that sends to a service running on DataPower, which by default sends responses as Transfer-Encoding: chunked. I need to be able to set up a route to use in a test case that simulates this service, but I can't see any way to tell a netty4-http consumer to send a chunked response. I've seen some old pages that suggest there is an option chunked=Boolean on the netty4-http component, but it is not mentioned in the 2.18 documentation. I tried setting it anyway, and it didn't seem to make a difference. At least, the message came back with a header chunked: true, but not Transfer-Encoding: chunked. When I hook up the route to the DataPower service, when I get the response body as a string, it still has the chunked encoding in it - a hex integer indicating the length at the start, and a zero on the end to indicate the last chunk. I'm expecting the body to be a JSON string, so first I have to chop of the chunked encoding parts to get the proper JSON. Seems weird that I have to do this manually. Is there another setting to tell it to use the right Transfer-Encoding? Colin Sharples "This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ Bank New Zealand Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication." "This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ Bank New Zealand Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication."
