Async throttled actions with disabled compression...

[genXdev]

A few actions of my controller, stream mpeg audio, throttled for limiting bandwidth.

I disabled compression on these actions, using the [Compression(Enabled = false)] attribute.

But this doesn't work, the pipeline message handler only checks this setting, after it has waited for the response to be generated. This makes this library useless for my project.

 protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
        {
            // Decompress compressed requests to the server
            if (request.Content != null && request.Content.Headers.ContentEncoding.Any())
            {
                await this.DecompressRequest(request);
            }

            var response = await base.SendAsync(request, cancellationToken).ConfigureAwait(false);

            var process = this.enableCompression(request);

            try
            {
                if (response.Content != null)
                {
                    // Buffer content for further processing
                    await response.Content.LoadIntoBufferAsync();
                }
                else
                {
                    process = false;
                }
            }
            catch (Exception ex)
            {
                process = false;

                Debug.WriteLine(ex.Message);
            }

            // Compress uncompressed responses from the server
            if (process && response.Content != null && request.Headers.AcceptEncoding.Any())
            {
                await this.CompressResponse(request, response);
            }

            return response;
        }

[jhadwen]

We are also seeing the same issue with content that is designed to be streamed. In fact this issue seems to have other effects even with non-streamed content. e.g.

• If compression is disabled then the LoadIntoBufferAsync is still called.
• This causes the media formatter (whether custom or inbuilt) to write to the stream
• As compression is disabled the response is returned unaltered
• Regardless of the content being loaded into the buffer the media formatter will, for a second time, write to the stream
• Basically all compression disabled calls perform content formatting twice

Seems to me though the simple fix is that prior to the try block, a check for !process should be called and return the response if so.

Also I'm not certain whether swallowing any exception makes sense either. Although in most cases the exception will be re-thrown the second time around it is easy to make this not the case (e.g. close the stream in the formatter). Also by swallowing the exception it again causes duplicate calls to the media formatter.