Hi Jerome, others, We've figured out what is going wrong by monitoring the traffic with Wireshark. The problem is indeed, as suspected, related to gzip encoding. I'll try to explain with one of the traces that we've captured:
1. Client sends a request to the proxy with "Accept-Encoding: gzip". 2. The proxy forwards the request to the back-end server adding "Accept-Charset: *" and "Accept-Language: *", but otherwise identical. 3. The backend server responds with 127 bytes of gzip encoded data, expanding to 145 bytes when decompressed. 4. The proxy forwards the response to the client, but sends the 145 bytes of uncompressed data. The proxy did remove the "Content-Encoding: gzip" header so that part is ok. HOWEVER: the response still indicates "Content-Length: 127". 5. The client receives the response from the proxy and returns the first 127 bytes to the calling code, resulting in premature end-of-stream errors. I think there are two options to fix this: 1) Let Redirector replace/remove the Content-Length header from the response 2) Let Redirector forward the compressed body as-is. We're very much in favor of the second option as that would benefit both the proxy (less processing overhead) and the client (less network traffic). Is this something that can be addressed sometime soon? Not sure where to start looking for supplying a patch myself. Regards, Arjohn ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3077059
