Lighttpd 1.4.20 源碼分析：狀態機（三）Response 返回流程詳解

經過請求處理，Lighttpd 進入 CON_STATE_RESPONSE_START 狀態準備返回響應。核心工作在 connection_handle_write_prepare，主要根據請求 Method 設置 Response Headers（特別是 Content-Length）。

connection_handle_write_prepare 核心邏輯

函數先判斷連接模式是否為 DIRECT（未經插件處理），再依 http_method 分支處理。OPTIONS 方法設置 Allow 標頭並清空 write_queue。隨後依 http_status 分類：

• 204/205/304：僅返回 Headers，設置 file_finished=1 跳過文件發送。
• 4xx/5xx：嘗試發送靜態錯誤頁面（errorfile_prefix），無則生成預設錯誤頁。
• 其他：正常響應體處理。

Content-Length 設置規則

• file_finished=1 且非分塊編碼：計算 write_queue 長度設置 Content-Length。
• HEAD 請求：同 GET 但無實體，設置 Content-Length 並清空 write_queue。
• 未完成文件傳輸：需 Content-Length 或 Transfer-Encoding: chunked 才能保持 keep-alive，否則強制關閉。

最後呼叫 http_response_write_header 將 Headers 寫入 write_queue，狀態機轉入 CON_STATE_WRITE。

CON_STATE_WRITE：數據發送流程

判斷 write_queue 非空且連接可寫，呼叫 connection_handle_write 發送數據。若不可寫或隊列空，退出循環等待 I/O 事件（在循環後的 switch 中向 fdevent 註冊 FDEVENT_OUT）。

connection_handle_write 內部機制

1. 呼叫 network_write_chunkqueue 發送隊列數據。
2. 先檢查流量限制，超限則加入 joblist 讓其他連接發送。
3. 設置 TCP_CORK 合併多次 write 提升效率。
4. 呼叫 srv->network_backend_write 實際寫入（多 OS 實現，如 mmap、sendfile 減少拷貝）。
5. 遍歷 chunk：MEM_CHUNK 直接 write/send；FILE_CHUNK 優先 mmap，否則 read+write。
6. 返回值：0 發送完畢，1 未完，-1 服務器錯誤，-2 客戶端關閉（均進入 CON_STATE_ERROR）。

CON_STATE_RESPONSE_END：收尾工作

1. 呼叫 plugins_call_handle_request_done 通知插件請求結束。
2. 判斷 keep-alive：是則重置狀態機至 CON_STATE_REQUEST_START；否則通知插件連接關閉、關閉連接、重置 con 清除上次請求數據。

返回響應流程相對直接，難點在於 HTTP 協議細節處理，建議參照 RFC 理解。