Details
-
Bug
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
2.23.1
-
None
-
I encounter this using the REST DSL with the servlet component, but I imagine its a more general problem. I
'm using Camel 2.18.0, but I checked and the problem seem to also happen with the latest version.
-
Unknown
Description
This has been discussed in the users mailing list [1], but there was no conclusion, and it looks like a bug or quirk so I'm raising this issue to try to get resolution.
The issue is that when writing the response of an HTTP request using a PipedInputStream to the Message body and with the `Content-Encoding: gzip` set as a response header the data does not seem to be sent until the entire stream has been written to the PipedInputStream. This means the client cannot start to read the response until the entire set of data has been written. When that header is not set the data is streamed immediately.
Also, symptomatic of this, when using `Content-Encoding: gzip` the `Content-Length` header gets set, which can only happen after the entire stream has been processed. Without the gzip header the 'Transfer-Encoding: chunked' header gets set and there is no Content-Length as you might expect. I would have expected this to happen even if the `Content-Encoding: gzip` header is set.
Is this a bug, or am I missing some magical way to ensure that the response is streamed when it is being gzipped?
[1]http://mail-archives.apache.org/mod_mbox/camel-users/201901.mbox/%3C9cc4adf0-91f2-a111-edce-e7a18fde9fdf%40gmail.com%3E