確定格式錯誤（錯誤）的 http 請求的結束
我正在實現一個 HTTP 伺服器，並想知道，是否有一種定義的方式來確定伺服器何時將錯誤請求確定為結束
- 返回相應的 400 狀態，以及
- 接受以下數據作為新請求，開始嘗試解析它。
我想到的唯一想法是一個非常模棱兩可的想法：搜尋接收到的下一個類似請求行的數據並從那裡開始新的解析嘗試。然而，如上所述，這是一種非常模棱兩可的方法，因為錯誤請求的數據當然可能包含所述“請求行式”數據，而實際上並不打算將其作為單獨的新請求。
在考慮對格式錯誤的響應進行客戶端響應解析時會出現同樣的問題，因此將不勝感激考慮這種情況。
經過一些考慮，很明顯沒有普遍適用的方法來確定格式錯誤的消息的結尾，因為消息總是包含一些自我描述的資訊位（例如
Content-Length標題欄位），使接收者能夠真正理解消息。例如，如果響應如下所示：HTTP/1.1 200 OK Content-Length: [ consider correct content length here ] Content-Type: text/html <html> <head> <title>Title</title> </head> <body> HTTP OK status messages look like this: HTTP/1.1 200 OK </body> </html>客戶端解析器一開始很可能會失敗，
<因為它期望另一個標題欄位名稱（由於 -header 之後的單個換行符Content-Type）不允許<. 此外，它應該（可能）不要在以下數據中“搜尋”另一個有效的 HTTP 響應，因為它可能會收到像給定的消息體，它說HTTP/1.1 200 OK，但是這不是新的響應。因此，對格式錯誤的 http 消息的最佳反應似乎是關閉連接，因為任何其他解釋接收到的以下數據的嘗試都不可避免地是模棱兩可的。
然而，這不是 RFC 中以任何方式指定的 AFAIK。也許是因為 RFC 更多地是關於定義標準，而不是關於處理非標準行為。
標頭以
\r\n\r\n. 您只需解析需要讀取的每個條目並將它們拆分為參數 strtok ? 或 strstr，或手動。如果您更多地談論 GET 行；
HTTP 協議對URI的長度沒有任何先驗限制。伺服器必須能夠處理它們所服務的任何資源的 URI ，並且如果它們 提供可以生成此類 URI 的基於 GET 的表單，
則應該能夠處理無限長度的 URI。 如果 URI比伺服器可以處理的長（參見第 10.4.15 節），
伺服器應該返回 414（Request-URI Too Long）狀態。
Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths.請參閱RFC 2616以使您的 Web 伺服器根據標準重新執行。
注意，如果你想支持 HTTP1.0+，請確保你也準備好使用 chunk 屬性，否則你的伺服器將達到 HTTP0.9 標準。