ASP.NET Web API GZip/Deflat 資料遺失迷航記

前情提要：參考(1)(2)，之前測試發現 ASP.NET Web API 有個查詢資料量不小(1.92 MB)，並且會有同等級的上傳行為，在 ASP.NET Web API 加入 GZIP/Deflate (解)壓縮來改善效能，資料由 1.92 MB → 50 KB 壓縮率約 40 倍，這是用一點 CPU 來改善效能的好範例。

同事回報，在測試區當資料量提升至 3.3 MB(3338506 bytes) 後，程式有機會(隨機)出錯(Exception)。

先來看 HTTP POST 流程：

RestSharp (RawData: Over 3.3 MB) → GZIP → GZIP ByteArray (79515 bytes) → HTTP POST → ASP.NET Web API

這是個 VSTO 的 Excel 應用程式，在讀取 Web API 資料之後，原封不同進行上傳(HTTP POST)動作，由側錄取得離線 RawData 約 3.3 MB，經過 GZIP 壓縮後得到約 78 KB 的 Byte Array 資料，最後使用參考(2)程式碼送出：

request.AddParameter("application/json", content.ToArray(), ParameterType.RequestBody);

接收流程：

ASP.NET Web API → DecompressionHandler → RawData → Web API life cycle

Web API 收到請求後安排一個 Message Handler 進行解壓縮後取得 RawData 之後，按 Web API 生命流程往下進行。

程式穩定運作，經過許多分析與測試後，在終於在 Web API 側錄到錯誤發生時的資訊：

在 DecompressionHandler 取得的 GZIP ByteArray 大小為 77889，很明顯小於原始的 79515，把解壓縮的 RawData 資料 Dump 出來後確實資料短少被截斷了，造成後續 Web API 在進行 ModelBinding 時的不正常 Exception。

NGINX Proxy 與 Windows Authentication 整合

最近在整合 NGINX 的 Reverse Proxy 時碰到一些 Windows Authentication 整合的問題，花費不少時間，特此筆記之。

一般的 Web App 在 NGINX Reverse Proxy 作用下都能正常運作，但內部網站有多許使用 Windows Authentication 功能來進行 SSO，例如，在 ASP.NET MVC 或 ASP.NET Core 的 View Page，只需透過一行 @User.Identity.Name 即可觸發瀏覽器進行身分驗證功能，在網域運作環境下，是不可多得好物。當然，你找網路可以找到許多教你設 proxy_set_header 的文章或討論：

青菜SOAP與蘿蔔REST，請選擇？

在 dzone.com 看到一篇比較 SOAP 與 REST 的文章整理的覺得不錯，簡單翻譯做個筆記。

SOAP 和 REST 都是 Web Service 通訊協定，在 REST 未風行之前，SOAP 長期以來都是 Web Service 服務介面的標準方法。不過，根據 Stormpath 的統計，目前已有超過 70% 的公開 API。

SOAP 與 REST 主要差異

當你在 Internet 上公開一個 API，REST 通過獨立且一致的介面進行操作，用以訪問命名資源。而 SOAP 將應用程式邏輯的元件公開為服務，而不是資料，並且它通過不同的介面來操作。簡而言之，REST 訪問資料，SOAP 透過更標準化的訊息模式集來操作。在大多數情況下，可以使用 SOAP 與 REST 來實現相同結果。

RESTful API, SPA, SEO 之三角關係

在 twMVC#28 的討論，有個學員問題一則有趣的問題：在導入 RESTful 架構後，純 JavaScript 執行環境(jQuery, AngularJs, React, ...)的前端要如何做 SEO？

Web資訊流：Database → Model → Server Render → HTML → Browser

SPA資訊流：Database → Model → RESTful API ⇆ JS Framework (Browser)

不論是傳統 ASP、ASP.NET (WebForms)、ASP.NET MVC 等都是以產出 HTML 為最終目標。但前端框架不斷爆發後，原本 Server Render 的角色不斷被 RESTful API 給取代，而前端則是各種框架(jQuery、React、Angular、Vue、...)來操作著 Browser 的 HTML 來進行畫面操作與互動。這類以 JavaScript 為核心的 SPA(Single Page Application) 頁面，對於 SEO(Search Engine Optimization) 而言是非常不友善的。

我本身專注在後端(Backend)且公司主要業務面向也非消費端，雖然知道一二，但回家深入瞭解一番之後，原來還有許多技術面向可以討論，以下就目前收集的到的資料討論。如果有更專精前端(Frontend)與前端 SEO 的朋友，也請不吝指教。

進行ASP.NET容器化-以ASP.NET MVC/Web API為例

要將 ASP.NET MVC / ASP.NET Web API 轉移至 Docker Container 中運行，看似麻煩，但其實非常簡單。以下討論不使用工具與使用 Visual Studio for Docker 工具來達成轉移的工作。