軟體主廚的程式料理廚房

微軟官方文件「在 Linux 上使用 Nginx 裝載 ASP.NET Core」使用的作業系統是 Ubuntu，我個人是偏好號稱萬年不掛的 CentOS，Linux 不同陣營之間的風格是有一點差異的，所以如果照著微軟官方的步驟套到 CentOS 上，一定會在某個地方覺得拐手，我就把到可以成功瀏覽網頁之前需要注意地方做個記錄。

在前一篇文章 [料理佳餚] ASP.NET Core 的虛擬目錄哪去了？中有提到，傳統 ASP.NET 的 HTTP Handler 及 HTTP Modules 的工作在 ASP.NET Core 是由 Middleware 來負責處理，這篇文章就來介紹撰寫 Middleware 的幾種方式。

在傳統 ASP.NET 的年代，我們別無選擇，寫好的 ASP.NET 應用程式只能 Host 在 IIS 上執行，其中虛擬目錄的服務是由 StaticFile 這個 HTTP Handler 來負責處理。

而 ASP.NET Core 內建就有 Kestrel 這個輕量化的網頁伺服器，不需要再依賴 IIS，但是脫離 IIS 之後，我們要怎麼設定虛擬目錄？

ASP.NET Core 內建的 DI Container 稍嫌陽春了一點，讓我懷念起 Autofac 提供的多種花式註冊方式，我決定把它召喚回來攜手共創未來，ASP.NET Core 2.2 到 3.1 有一些 Breaking Changes，設定方式會有一點不一樣，這邊做個記錄。

以往服務參考（Service Reference）只能參考 Web Service 或 WCF，但是在把玩 gRPC 服務的過程中，意外地發現，原來在 Visual Studio 2019 已經可以透過服務參考的方式，為 gRPC 服務自動產生客戶端的程式碼，甚至是 Web API 也可以。

這幾天在把玩著 ASP.NET Core 的 gRPC 服務，正當思索著要怎麼實作 AOP（Aspect-Oriented Programming）時，我就看到了 GrpcServiceOptions 有一個 Interceptors 屬性，看到 Interceptor 這個關鍵字就知道 gRPC 服務天生就支援 AOP 的實作。

gRPC 服務預設會使用 HTTPS，不過這個只有針對 localhost 這個網域名稱，這天我想要將自己的區域網路 IP 指定為 gRPC 服務的端點，好做一些驗證跟測試，於是我就動手修改了 Kestrel 監聽的 IP，使用的是 HTTP 協定，然後就在客戶端收到了這個錯誤訊息。

IOException: The response ended prematurely.

gRPC 服務底層使用 Protocol Buffers 做為序列化的格式，與我們經常使用的 JSON 格式相比之下，其大小已經小非常多了，如果我們還覺得不夠，想要再更進一步地減少傳輸量，可以啟用 gRPC 服務的壓縮（Compression）機制，讓傳輸的資料量再更少一些。

這天在追查為何 A 客戶的訂單會出貨到 B 客戶哪裡去？　於是我看到了下面這段程式碼：

在 Login 的 Action 上面被加了 OutputCacheAttribute，Duration 屬性被設成 3，其中還用到了 VaryByParam 屬性，我猜寫這段 Code 的工程師應該是想要為每個登入的帳號做 OutputCache，這樣設定沒有問題，問題出在 HTTP Request 的發送內容。

gRPC 全名叫 gRPC Remote Procedure Calls，是一個由 Google 開發的 RPC 框架，基於 HTTP/2 協定及 Protocol Buffers 序列化協定設計而成的，主打著高性能、跨平台、跨語言（這一點頗吸引我），我們可以將 gRPC Host 在 ASP.NET Core 上做為一個服務發佈出去。