Hi, Tim! I'd suggest trying to intercept / dump the HttpAsyncClient request as well as the curl one. A simple "nc -l -p 8888" in an *NIX OS will do.
My guess is that the perceived difference lies in the request headers. Might be in the Accept. Can you post both requests in full, body excluded? Thanks! On Wed, 16 Jan 2019, 14:46 Tim Dudgeon <[email protected] wrote: > I'm hitting a strange problem with a route that is using the servlet > component to send a large stream of data in its response. > This is part of a route that uses the REST DSL which is set up like this: > > restConfiguration().component("servlet").host("0.0.0.0"); > > The route sets the response body as an PipedInputStream and then (in a > separate thread) writes to that InputStream and eventually closes it. > The expectation is that as the response size is unknown the data will be > chunked and response returned to the client immediately and the client > will start to consume the data immediately. > > When using curl as the client it seems to be working correctly, and I > see a 'Transfer-Encoding: chunked' header in the response. > > However my real client is Apache HttpAsyncClient and with that what I'm > seeing is that the response is not returned until all the data is > written, and instead of a 'Transfer-Encoding: chunked' header I see a > 'Content-Length: 19196336' header suggesting that Camel has waited for > the entire content to be written so that it can set the Content-Length. > I tried manually setting the 'Transfer-Encoding: chunked' in the > response message but it did not appear and instead I saw the > Content-Length header. > I've got HttpAsyncClient working in a test example to prove that it can > received the response asynchronously, so I think (but can't be sure) > that the problem is on the server (Camel) side. > > What can explain this different behaviour from the same service when > using different clients? > >
