Client, Socket adapter: compressed responses not decompressed when streaming #91
Description
The default Client pathways that use the Socket adapter automatically handle gzipped and deflated response bodies, and therefore include them in the Accept-Encoding header outgoing on responses as long as the zlib extension is present.
This automatic handling doesn't extend to the streaming support, however. In addition, the Client doesn't account for this fact and will still send an Accept-Encoding header indicating deflate and zlib are acceptable. The result is that the server will obey the Accept-Encoding header and send a compressed response, none of the Client, the Adapter, or the Response will decompress it, and it will be streamed as-is, in compressed form.
Because of the workflow involved in using the client, calling code can't know to add a decompression stream filter, as it would have to inspect headers to determine if the response was in fact compressed, but by the time those headers are available, send()
has already been called and the data has already been streamed to its destination. The best available workaround is to manually set an Accept-Encoding header to tell servers that compression is not supported when using streams.
The Client should either not send the Accept-Encoding header when setStream has been called, or the Client or Adapter should automatically attach an appropriate stream filter to decompress the response according to the response headers.
This appears to be the same issue as the longstanding ZF1-era issue ZF-10878. I'm not sure how or if it's related to #89 which is Curl-specific and doesn't require streaming.