Issue with using compression on the remote side

[Licenser]

It seems that when enabling compression to the remote side ring-proxy has a problem. From what I can tell the following happens:

1. the http request is send offering gzip and dflate compression

GET /api/0.2.0/vms? HTTP/1.1
Connection: close
cache-control: no-cache
accept-encoding: gzip, deflate
authorization: Bearer iH89VF89i04IfPYucIpbOrLRLzvIqZQb
accept-language: en-US,en;q=0.8,de;q=0.6
accept: application/json
pragma: no-cache
connection: keep-alive
referer: http://localhost:8888/
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.89 Safari/537.36
Host: 192.168.221.201:8080

2. the response is returned (with gzip)

HTTP/1.1 200 OK
connection: close
server: Cowboy
date: Sat, 21 Mar 2015 22:17:57 GMT
content-encoding: gzip
content-length: 296
access-control-allow-origin: *
access-control-allow-headers: Authorization, content-type, x-snarl-token, x-full-list, x-full-list-fields
access-control-expose-headers: x-snarl-token, x-full-list, x-full-list-fields
access-control-allow-credentials: true
content-type: application/json
vary: accept

<296 byte of gzip encoded binary data>

3. The Java HTTP client reports a content-length header of 296 as is correct but already decodes the body.

4. https://github.com/tailrecursion/ring-proxy/blob/master/src/tailrecursion/ring_proxy.clj#L42 Copies the amount of bytes in content-length

5. given the decompressed data is larger the compressed one part of the data is cut of when resending.

[npetryk]

If anyone is still interested in this issue, it can be fixed by adding :decompress-body false to the clj-http.client/request map