Lighttpd 1.4.20 源碼分析：狀態機（二）連接請求處理全流程

本文透過狀態機視角，詳細剖析 Lighttpd 處理靜態頁面請求的完整流程（核心插件 mod_staticfile 為預設載入）。

狀態機流轉總覽

關鍵狀態逐層解析

CON_STATE_REQUEST_START → CON_STATE_READ

記錄連接建立時間等標記，進入 READ 狀態從連接讀取 HTTP Headers 存入 con->request.request。可能需多次讀取，狀態保持 READ 直到讀完，轉入 CON_STATE_REQUEST_END。

CON_STATE_REQUEST_END：HTTP 解析

核心呼叫 http_request_parse 解析 Request：

• Request Line → http_method、http_version、uri
• Header Lines → 存入 request.headers（array of data_string）
• 檢查 POST 數據：有則進入 CON_STATE_READ_POST，否則進入 CON_STATE_HANDLE_REQUEST

CON_STATE_READ_POST：大數據處理

邏輯與 READ 類似，但 connection_handle_read_state 後段分流。<64KB 存 buffer，>64KB 存臨時文件，每文件 1MB。POST 數據存入 request_content_queue（chunkqueue 鏈表），chunk 結構支援記憶體 (MEM_CHUNK) 與文件 (FILE_CHUNK + mmap) 兩種存儲，unused 棧池化管理提升效率。

CON_STATE_HANDLE_REQUEST：核心處理入口

呼叫 http_response_prepare（response.c），此函數為服務器與插件系統交互核心，密集呼叫 plugins_call_handle_xxxx 接口。流程：

1. uri_raw：未解碼 URL path，典型用於 Proxy 直接轉發。
2. uri_clean：解碼後 URL path，同樣用於 Proxy。
3. docroot：設置處理根目錄，支援虛擬主機。
4. physical：拼接物理路徑（docroot + rel_path），插件據此處理。
5. subrequest_start / subrequest：子請求處理階段。

若無插件接管且模式為 DIRECT，靜態文件檢查：stat_cache_get_entry 確認文件存在，否則嘗試 PATHINFO。最終若仍無插件處理，依方法設置狀態碼（OPTIONS→200，其他→403）。

插件接口職責總結

處理完成進入 CON_STATE_RESPONSE_START，準備響應頭與寫入數據（下文續述）。