【发布时间】:2013-06-19 01:34:56
【问题描述】:
我正在为 web-api 应用程序进行一些压缩/解压缩。
感谢网络上的multiple articles 和questions posted here,我已经实现了大部分。
但是,我仍然被困在一个甚至还没有受到质疑的问题上。
简而言之,我需要支持大量数据的流式传输,包括响应和请求,并且都是压缩的。我已经实现了DelegatingHandler 并创建了 2 个HttpContent 类,一个用于压缩内容(响应),另一个用于解压缩内容(请求)。
使用以下代码压缩响应完美
protected override Task SerializeToStreamAsync(System.IO.Stream stream, System.Net.TransportContext context)
{
Stream compressionStream = this.Compressor.CreateCompressionStream(stream);
return this.OriginalContent.CopyToAsync(compressionStream).ContinueWith(task =>
{
if (compressionStream != null)
{
compressionStream.Dispose();
}
});
}
我创建一个压缩流并将原始内容复制到压缩流。但是,在解压缩请求时,我目前正在使用以下代码。
protected override Task SerializeToStreamAsync(System.IO.Stream stream, System.Net.TransportContext context)
{
Stream compressionStream =
this.Compressor.CreateDecompressionStream(
this.OriginalContent.ReadAsStreamAsync().Result);
return compressionStream.CopyToAsync(stream).ContinueWith(task =>
{
if (compressionStream != null)
{
compressionStream.Dispose();
}
});
}
如您所见,我有义务将原始请求作为流读取,然后再将其复制到解压缩流并将其进一步发送到管道中。
当大量数据发布到服务时,这可能不是一个好习惯。 那么现在的问题是,这是正确的方法吗?我一直在寻找一种无缝的方式来做到这一点。
我正在考虑实现Blocking Stream(适应新的 TAP),但我再次陷入困境,因为 HttpContent 完全是 TAP,这意味着一切都返回一个 Task 对象,我需要一个实际 Stream 的句柄。
【问题讨论】:
标签: asp.net-web-api compression