This question詢問'基於cgi-bin'的服務的缺點。據我所知，除了可能的命名約定之外，就基於Web的客戶端/服務器交互而言，多年來沒有什麼變化。當然，現在可以選擇使用AJAX客戶端，但最終它們仍然是無狀態的，無論編寫哪種語言，服務器上的代碼仍然等待輸入通過「GET」或「POST」方法發送。替代cgi-bin
就網絡編程而言，已經走出循環一段時間了，我是否錯過了一些明顯的東西？
澄清我的問題：我提到的問題表明'cgi-bin'系統不再使用，新的替代方案是什麼？
@sarnold。謝謝您的回答。即使系統是使用「最新最好的」服務器平臺開發的（我猜這將是一個基於.net的系統或Linux等價物），但它最終仍然只是一個程序，或程序，運行（如果使用快速CGI）或等待在服務器上啓動，所以多年來確實沒有任何變化。如果這是另一種方法是布賴恩提到的情況在他的question?
最大的變化是在工具，如它們實現一些非常幾乎完全相同mod_php直接在Web服務器的地址空間執行的代碼和FastCGI CGI協議，但有少量長壽命進程，而不是每個請求的新解釋器的fork(2) + execve(2)。
當然，這兩種方法都存在問題：直接在Web服務器的地址空間中執行解釋器對於可靠性和安全性來說可能是非常可怕的：服務器（通常）始終以相同的權限運行，因此將用戶分開（通常）不可能。此外，解釋器中的缺陷可能相當普遍，所以它不適用於共享主機環境，因爲任何用戶都可以使用訪問系統上所有其他用戶的所有數據所需的特權運行任意代碼。
FastCGI方法幾乎保持相同的速度;它確實犧牲了在進程間複製數據的速度，但對於除了巨大的卷網站之外的任何人都不是什麼大問題。但是，您可以將多個FastCGI系統作爲連接到單個「Web服務器」不同位置的不同用戶帳戶運行（例如，http://example.com/public/在帳戶www-public和http://example.com/private/下運行，帳戶www-private下運行），並且FastCGI系統無需運行與Web服務器相同的權限。
當然，也有servlet systems其中服務器調用鏈接到服務器進程的編譯回調（經常編譯爲字節碼）代碼。更少的「腳本」 - 感覺。