runtime: HttpClient deflate decompression error
Hi, I just tried to move project from Net 5 to latest preview of Net 6 and I have noticed issue with automatic decompression. Gzip and Brotli seems to work fine, but Deflate is throwing IO error with invalid stream data. When I change back to Net 5, everything works fine again. Here is part of code that throws the error on last line with stream.ReadAsync. I think this happen only when the website is using https and I receive response compressed with Deflate, also the HttpCompletionOption.ResponseHeadersRead might be causing some issue.
var _httpClientHandler = new SocketsHttpHandler
{
AutomaticDecompression = DecompressionMethods.All
};
var _client = new HttpClient(_httpClientHandler, false);
var response = await _client.SendAsync(request, HttpCompletionOption.ResponseHeadersRead,)
if (response.IsSuccessStatusCode)
{
Stream contentStream = await response.Content.ReadAsStreamAsync(_token);
if (contentStream != Stream.Null)
{
int readBytes = 0;
var rentedBuffer = pool.Rent(64 * 1024);
var bufferMemory = new Memory<byte>(rentedBuffer, 0, rentedBuffer.Length);
int readChunk = await stream.ReadAsync(bufferMemory.Slice(readBytes));
}
}
System.IO.InvalidDataException: The archive entry was compressed using an unsupported compression method.
at ErrorCode System.IO.Compression.Inflater.Inflate(FlushCode flushCode)
at ErrorCode System.IO.Compression.Inflater.ReadInflateOutput(Byte* bufPtr, int length, FlushCode flushCode, out int bytesRead)
at void System.IO.Compression.Inflater.ReadOutput(Byte* bufPtr, int length, out int bytesRead)
at int System.IO.Compression.Inflater.InflateVerified(Byte* bufPtr, int length)
at async ValueTask<int> System.IO.Compression.DeflateStream.ReadAsyncMemory(Memory<byte> buffer, CancellationToken cancellationToken)+Core(?)
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 23 (11 by maintainers)
This is the heuristic I was investigating doing before I convinced myself it wasn’t sufficient. But thinking about it further, I realize the error in my logic. Iwas comparing the protocols in general, and in general, that’s not a sufficient heuristic, e.g. ZLibStream itself couldn’t do it, because the first nibble indicates the compression algorithm and it could be anything. But in the context of http, the response is limited to a zlib wrapper around deflate, which means in that context the first nibble will be 8.
I’ll see if I can make this work later today.
@karelz I don’t run this against any servers. This issue is just interesting to me because I have hit the same problem years ago in an entirely different HTTP client.