#20 Bad response writing for Transfer-encoding: chunked

[Jimmy Van Broeck]

When a webserver at the other end responds with transfer-encoding: chunked.
The stream is outputting wrong data. It should follow the chunked encoding response from the server and output the number of bytes, followed by the content and then flush the stream.

[Jimmy Van Broeck]

patch that uses chunked transfer encoding

[Nobody/Anonymous]

Please test your patch before uploading it here. After patching proxy adds numbers to the content.
And the httpclient already does this for us(it uses ChunkedOutputStream internally).

Btw, why does proxy always cuts Content-length header?

[Nobody/Anonymous]

Hi

When there is a apache with mod_jk in front of the reverse proxy, then it fails. The problem is chunked encoding. The header is set, but it is from the source which as been called. This results in a white page, mostly in firefox. The fix is to remove the

encoding header and letting the tomcat put it on again.

This is my fix for the problem
BasicResponseholder.setHeaders

boolean encoding = name.equalsIgnoreCase("transfer-encoding");

if (!contentLength && !connection && !encoding) {

[Anonymous]

I also had the problem where a soap client was choking on a response from the proxy containing the chunked transfer-encoding header but the content was not actually chunked formated.

The patch suggested on 2009-08-14 08:42 fixed the issue for me and seems reasonable.