我想擴展我的REST服務(使用WCF/webHttpBinding構建),以便客戶端可以上傳經過壓縮的數據。我不確定要達到這個目的的最佳方式,但是我認爲通過添加一個HTTP模塊可以相當容易,該模塊將在傳入請求的Content-Encoding設置爲gzip時解壓縮數據。我可以使用HTTP模塊更改傳入HTTP請求的內容嗎?
所以我創建了一個類從IHttpModule的導出具有以下實現:
private void OnBeginRequest(object sender, EventArgs e)
{
var app = (HttpApplication) sender;
var context = app.Context;
var contentEncoding = context.Request.Headers["Content-Encoding"];
if (contentEncoding == "gzip")
{
// some debug code:
var decompressedStream = new GZipStream(context.Request.InputStream, CompressionMode.Decompress);
var memoryStream = new MemoryStream();
decompressedStream.CopyTo(memoryStream);
memoryStream.Seek(0, SeekOrigin.Begin);
var streamReader = new StreamReader(memoryStream);
string msg = streamReader.ReadToEnd();
context.Request.InputStream.Seek(0, SeekOrigin.Begin);
app.Request.Filter = //new TestFilterStream(app.Request.Filter);
new System.IO.Compression.GZipStream(
app.Request.Filter, CompressionMode.Decompress);
}
}
我看到的問題是,從來沒有實際執行GZipStream減壓。我已經確認傳入的數據實際上是gzip'd(msg變量包含正確的數據)。我也嘗試創建我自己的流類(TestFilterStream),並將其分配給app.Request.Filter,並且我確認了流類中沒有成員實際上由ASP.NET調用。所以看起來好像雖然可以指定一個過濾器,但實際上並未使用該過濾器。
是不是實際使用了HttpApplication.Request.Filter?
你有沒有嘗試過設置'Request.Filter'沒有你的其他調試代碼?這可能是因爲您已經閱讀了請求流,因此它不會再應用此過濾器。 –
我相信沒有理由相信Request.InputStream是可搜索的。它可能不是。嘗試刪除你的調試代碼,它可能是錯誤的(你可能必須關閉/沖洗decompressedStream才能真正寫入內存流)。 – Luaan
請縮小這個問題的範圍,因爲從您的問題中不清楚實際發生的錯誤以及何時發生。問題實際上'GZipStream'沒有讀取底層流? 'contentEncoding'等於''gzip「','if'塊中的代碼被調用了嗎?您是否嘗試過記錄此方法被調用的時刻?你甚至確定你的模塊被加載了嗎? – CodeCaster