Potential memory issue

[damianh]

Hi, nice lib.

https://github.com/azzlack/Microsoft.AspNet.WebApi.MessageHandlers.Compression/blob/master/src/Microsoft.AspNet.WebApi.MessageHandlers.Compression/ClientCompressionHandler.cs#L103

If downloading large gzip response will this will buffer the complete response before decompressing? If so, is it wise?

Does the lib supported chunked responses?

Cheers

[azzlack]

Yes it does buffer the complete response as I haven't found a way to calculate Content-Length without doing that first. If you know of a way, please let me know :-)

[damianh]

A potential strategy would be to have an initial buffer, say 64KB (make it configurable) and if the response entity fits in this in it's entirety, compress it all and you have your Content-Length. If the entity exceeds the buffer size, use chunked transfer encoding instead.

[azzlack]

Done some to improve this, but some responses need to be buffered to properly calculate content-length. http://blogs.msdn.com/b/kiranchalla/archive/2012/05/14/response-buffering-amp-chunking-in-web-host-scenarios.aspx

Leaving this open for further improvement

[ahmedalejo]

I guess System.Net.Http.HttpContent.TryComputeLength should be more appropriate, but since it´s protected a wrapper ``HttpContent` could be used expose this method.

Or simply ignore content length since GzipStream doesn´t need to know the length of the stream to be compressed(correct me if i´m wrong)

[RedwoodForest]

We need to compress requests/responses that may be tens or hundreds of megabytes in size.

This along with #45 are preventing us from using this library instead of this code.

I think @ahmedalejo's suggestion approach makes sense the same way that, e.g., StreamContent reports that the length is unknown when the stream is not seekable.