做好了最基本的測試來做好QA，以及利用自動化的方式來提昇開發效率後，該繼續前進了。之前寫的伺服器程式，其實都只是簡單的發想與實做而已，所以現在需要針對伺服器需求，來考慮怎麼做好設計。
http的支援
http本身的結構很簡單，就是request+response，node.js的http/https模組，也在request事件中，提供了這兩個物件，來支援http的操作。
之前開發的伺服器程式中，只針對了http request結構中的host、method、path做處理，但是讓http能夠提供各種各樣服務的能力，還有一個重點是header的處理。以cookie為例，他的生命週期是client在控制，只要cookie還有效，request中就會有cookie這個header。伺服器也需要有能力設定cookie，要設定cookie的話，需要在response中加入setcookie這個header。server收到的所有request header，其實都是一個字串，所以收到以後，還需要有適當的parser來處理他。回傳的response header也是一個字串，所以需要依照規格中制定的格式來產生他。這些是處理header至少需要做的事情。
request header跟request body的處理會有關係，例如在post的時候送出form data，通常會收到url encoded格式的request body，需要剖析他來取出html form傳來的資料。如果是上傳檔案，那會收到multipart/form-data格式的資料，同樣也需要有適當的方法來處理。
request header也可能會跟response body有關係。例如收到的request headers裡面有range header，那就需要做處理，依照range裡面要求的資源的start與end的offset來讀取資源來寫入response body。
整理一下可能的需求與流程變化：
看起來是互相影響，很難使用單純的流程來處理所有的header。不過大致上可以區分為：
不影響伺服器流程的header handler，可以考慮把處理後的資訊寫入request物件，之後的流程可以視需要使用這些資料。
依條件影響伺服器流程時，會依照條件判斷，是否要進入伺服器處理的標準流程。
改變伺服器流程的話，則完全不會進入伺服器處理的標準流程。
依照http可能發生的狀況，以及之前設計好的fs mapping/router機制來設計伺服器流程的話，可以考慮分成三個流程：
伺服器可以根據功能的需求，自訂要載入的handler，但是如果把dispatch流程放在處理header之後會有一個問題，就是無法依照各個router規則或是path來設定處理方式。這個要再想想。
分工與協作的考量
除了達成http伺服器該有的功能，使用者怎樣使用也是一個重要的考量。
之前設計好的router機制，已經可以讓使用者自己任意撰寫伺服器端的程式，但是還是需要考慮到使用者的需求來設計更細部的流程。這裡主要得考量有：
初步設計
考慮了一下node.js運行的方式，基本上雖然在程式裡面寫好了一些比較動態的功能載入方法，實際在運行時，在node.js載入程式時就會做好編譯，這樣的話依照每個host或路徑規則載入功能其實不太有意義。
所以要設計載入功能的話，可以把每個要載入使用的功能，例如cookie、auth、session、range等等，依照規劃好的三個階段：pre-dispatch、dispatch、post-dispatch，把功能切成三個部分，一些要自動處理或是要在dispatch之前處理的程式，就把它放在pre-dispatch。需要在程式中給開發者呼叫的功能，則利用一些方法dispose給開發者使用。至於post-dispatch的部份，以及需要設計view layer的功能的部份，我想等到稍後在來考慮。
在pre-dispatch中，可以決定是否要進入dispatch，還是要跑自己的流程。
在dispatch中，實際上是在已經dispatch完畢的route handler中跑，這時候可以自己考慮是否要進入標準的post-dispatch流程，或是結束。
這樣切清楚以後，就可以實作流程的機制與handler的標準，另外，如果要開放撰寫handler plugin，這樣也有一定的設計方法。這些等到明天再來做吧。
iThome鐵人賽
看影片追技術