操縱HTTP響應

Question

我現在的問題是密切相關的this one，但更爲具體。我們必須爲這個問題中描述的目標規劃一個設計策略。

我們想通過來重寫ASP.NET網頁表單上的HTML。我的問題是：根據參數的可行性,性能影響和在傳統應用的實施努力，哪個策略是最好的。

我要做

是基本上得到一個Web窗體的HTML輸出，分析它，並根據用戶定義的規則替換某些URL。在那個例子中，我會將所有靜態內容重寫爲CDN URL，但它可以很容易地擴展到URL重寫技術。我發現很多（我真的是很多）的約URL不必像http://myblog.com/2092網址解釋爲http://myblog.com/Default.aspx?post=2092的角度改寫文章，但我沒有發現我展示如何巧妙格式舊式的URL縮短格式正確從HTML內部（所以頁面將直接渲染短格式的URL）[編輯]沒有深入的代碼干預。

策略1

像在上述問題的回答表明，寫截取HTML和重寫它的HTTP模塊。實際上，我環顧四周，看到我可以設置一個執行HTML過濾的流對象Response.Filter。

• 優點：我可以注入上的遺留應用的HTTP模塊，經由XML配置重寫規則，並且具有從CDN最古老的CRM /電子商務應用負載的靜態內容，而完全不觸摸它的代碼。
• 缺點：我懷疑（和註釋here確認本人嫌疑人），其具有重新實現Stream的Write方法，該方法在一般情況下的局部緩衝器工作，可能會導致不良的替代品。假設Write方法首先用ttp://mydomain.com/static/ima（我假定<img src="h已被寫入之前）和後面的ge.png" />（因此猜測最終的URL :-P）這樣的塊用一個重寫規則代入http://cdn.com/path/$1的重寫規則調用，但替換沒有完成。要解決這一點，我可以用一個MemoryStream或類似的東西來緩衝一套完整的數據，然後進行換人，但它可能會導致在高負載的服務器

策略2

重寫的煩惱Page的Render方法的方式，例如描述here

• 優點：不會受到分塊問題
• 缺點：需要爲所有頁面定義基類。在新的應用程序上可行，不保證傳統的應用程序。似乎已經因爲你不能實例化一個問題HttpTextWriter直接

顯然，對於新的webapps我們必須要發展，我會採取策略2，但我真的很喜歡使用動態組件了很多，因爲他們可以當應用程序需要它們時可以輕鬆插入（因此，如果我們的新應用程序將在沒有CDN的情況下安裝，則關閉此功能）。

簡單地說，我的問題是

你如何解決這兩個戰略缺點（尤其是第一次）？當然，您是否有其他策略可以實現這一目標？

謝謝。

Answer 1

也許你可以使用ASP.NET的「自適應控制行爲」功能。請參見Architectural Overview of Adaptive Control Behavior

基本上，您會重新定義一個新的HtmlTextWriter類，將其關聯爲默認渲染器，並使用您自己的代碼覆蓋「A」標記渲染。