默認情況下，許多庫在所有HTTP 1.1 POST和PUT請求中包含Expect: 100-continue。空「預期：」標題意味着什麼？
我打算通過刪除客戶端上的100-繼續機制來減少感知的延遲，因爲我知道立即發送數據的費用少於等待100次繼續的往返，即短期請求。
當然我還想要HTTP 1.1的所有其他強大功能，因此我只想殺掉Expect: 100-continue頭。我有兩個選擇：
Expect:\r\n是否有過兩者之間有什麼區別？
任何軟件可能會破壞一個或另一個？
應該休息，如果你刪除Expect頭，但我知道，微軟的IIS已經有問題在過去
100 Continue
沒有。例如，IIS5 always sends 100 continue responses。所以，我想知道它在圖書館中的至少一些用途可能是解決服務器中類似的破壞行爲。
很多圖書館似乎設置了此標題，然後實際上並未正確處理100 Continue - 例如，他們開始立即發送請求主體而不用等待100 Continue，然後不處理服務器可能在發送請求主體之前發回任何HTTP錯誤代碼這一事實（第一部分的確定，它是第二部分這是破碎的 - 見我的答案）。這使我相信有些作者剛剛從其他地方複製它，但沒有完全理解the subtleties。
我看不到任何理由包含一個空白Expect標題 - 如果你不打算包括100-continue（或其他一些Expect子句），那麼完全省略標題。包含它的唯一原因將是解決破碎的Web服務器，但我不知道有哪些行爲以這種方式。
最後，如果你只是想減少往返延遲，在我看來，它不會實際上是與RFC不一致只是立即開始傳輸請求主體。你不應該無限期地等待發送請求主體（根據the RFC），所以你的行爲符合規範 - 只是你的超時在發送之前是零。
您必須意識到，如果服務器已收到一些請求主體，那麼服務器可以自由發送100 Continue響應，因此您必須處理髮送100 Continue的服務器，這些服務器不發送任何內容並等待滿請求和立即發送任何HTTP錯誤代碼（可能是417，但更可能是通用4xx代碼）的請求。這樣，你的短請求不應該有任何開銷（除了Expect標題），但你不必等待100 Continue。當然，要使這種方法起作用，您需要採取一種辦法，讓服務器返回錯誤代碼（例如，使用poll()或select()的非阻塞IO）立即中斷請求。
這樣做可能有助於保持代碼在小請求和大請求之間的一致性，同時減少延遲。不足之處在於，即使它沒有明確違反任何要求，也可能不是RFC的作者所想的。另外，如果您還沒有進行非阻塞IO或類似操作，它可能會使您的後續代碼更加複雜。