沒有http標頭的Http響應

Question

我已經寫了一個迷你極簡主義的http服務器原型（很大程度上受到了升級asio示例的啟發），而且目前我還沒有在服務器響應中放置任何http標頭，只有html字符串內容。 令人驚訝的是，它的工作正常。

在那個問題中 ，OP想知道http響應中的必要字段，其中一條評論表明它們在服務器端可能並不重要。

我還沒有嘗試過響應二進制圖像文件，或者暫時壓縮gzip壓縮文件，在這種情況下我認為必須有一個http標頭。

但對於純文本響應（html，css和xml輸出），是否可以永遠不要在我的服務器響應中包含http標頭？ 可能存在哪些風險/錯誤？

Answer 1

您必須至少提供包含狀態行和日期的標頭。

作為編寫了許多協議解析器的人， 我懇求你 ，在我的數字隱喻的膝蓋上， 請求哦哦請不要完全忽略規范只是因為你最喜歡的瀏覽器讓你逃脫它。

只要它生成的數據是正確的，創建一個功能最少的程序就完美了。 這不應該是一個主要的負擔，因為您只需要在響應開始時添加三行。 其中一條線是空白的 ！ 請花幾分鍾時間編寫兩行代碼 ，這些代碼將使您的響應數據符合規范。

你真正應該提供的標題是：

• 狀態行（必填）
• 日期標題（必填）
• 內容類型（強烈推薦）
• content-length（強烈推薦），除非你使用的是chunked編碼
• 如果您要返回HTTP / 1.1狀態行，並且您沒有提供有效的內容長度或使用分塊編碼，那么添加Connection: close您的標題
• 將標題與正文分開的空白行（必填）

您可以選擇不使用響應發送內容類型，但您必須了解客戶端可能不知道如何處理數據。 客戶端必須猜測它是什么類型的數據。 瀏覽器可能決定將其視為下載文件而不是顯示它。 自動進程（某人的bash / curl腳本）可能會合理地確定數據不是預期的類型，因此應將其丟棄。

來自HTTP / 1.1規范部分3.1.1.5。 內容類型：

生成包含有效負載主體的消息的發送方應該在該消息中生成Content-Type標頭字段，除非發送方不知道所包含的表示的預期媒體類型。 如果Content-Type頭字段不存在，則接收者可以采用媒體類型“application / octet-stream”（[RFC2046]，第4.5.1節）或檢查數據以確定其類型。