軟體主廚的程式料理廚房

有一些專案它的生命週期不長，像是商業活動專案，活動過了，專案也就跟著結束，如果使用者不多，而且使用者大都集中在某個時段才會操作系統，那 Azure Functions 是挺合適的解決方案；又或者，我們有一些排程工作，執行的間隔時間很長，可能一天才一次，用 Azure Functions 也很適合。

以前聽過有個笑話是這樣說的：

某A：聽說 iOS 在瀏覽網頁的時候很省電
某B：對，因為它什麼事都沒做。

原來這件事是真的，根據 RFC 7234 5.2.1.4 的定義，如果我們在發送 Request 的時候，加上 cache-control: no-cache，在沒有從伺服器成功取得內容之前，不得使用已儲存的快取來滿足目前的 Request，但是 iOS 它連 Request 都沒送，自然就不需要理會這個定義。

先前有寫過一篇個人常用的 ASP.NET MVC 自訂 HTTP 回應碼畫面的套路，一切看起來都很好，但是當使用者輸入一些資料，驗證不通過的時候，想要送 400（Bad Request）順便在 Body 中塞入一些訊息回傳給使用者，不做點調整是做不到的。

如果我們認真要用 ASP.NET MVC 做一個對外服務的網站，直接赤裸裸地爆黃白畫面在使用者面前，實在不是那麼優雅，如果從 Web.config 著手要自訂錯誤畫面的話，那麼 Google 到的答案大致就兩個方向：<system.web>/<customErrors> 及 <system.webServer>/<httpErrors>。

程式的生命週期往往比我們想像中的長，通常年紀愈大的程式包袱愈重，後面接手的人肩負的壓力也愈重，如果我們知道有一個字串叫 http://www.xxx.com ，現在因為政策的關係必須改成 https://www.xxx.com ，偏偏 http://www.xxx.com 被到處寫死在資料庫及程式原始碼裡面，除了把寫死的那些找出來改之外，我們還可以怎麼做？

之前有介紹過 SSL 憑證只要放在 Load Balancing 就可以了，不必在每台 Load Balancing 後面的機器都去放置 SSL 憑證，假設我們原有 http://xxx.yyy.com 的網址，在我們打通了 https 之後想要將 http 都強制重新導向到 https，很直覺地我們想到的解決方案就是檢查打進來的 Request URL 如果是 http:// 開頭的就回應重新導向到 https:// 開頭的就行了，但死亡導向之門也就此被打開了。

HTTPS 協定已普及化了，甚至我們的網站如果沒有支援 HTTPS 的話，在搜尋引擎的排名還可能會被調降，本篇文章就在 IIS 8.5 躲藏在 GCP Load Balancing 背後的環境下，一步步去打通 HTTPS。

之前提到的 ngBind、{{ }}、ngBindHtml、ngBindTemplate 資料綁定 是屬於單向資料綁定，也就是說在畫面上修改的值，不會回寫到 Model，當我們需要把使用者輸入的訊息回寫到 Model 時，可以使用 ngModel 這個雙向資料綁定的 Directive。

之前扒網頁扒到「伺服器認可通訊協定違規. Section=...」的問題，決定追根究柢一下，這個訊息不是只有在用 RestSharp 接收 Response 時會這樣，用 Fiddler 做側錄的時候也會跳出警告訊息來。

用 RestSharp 扒到一個沒看過的 ErrorException（伺服器認可通訊協定違規. Section=ResponseStatusLine），明明用 Postman 打它就好好的沒問題。