在HEAD響應中避免內容長度

內容長度響應頭對於剛纔的HEAD請求（例如，當處理動態生成的資源時）通常很昂貴，但在完成生成所需的工作後可能基本上是「免費的」一個GET響應體。在HEAD響應中避免內容長度

如果在響應GET請求時提供Content-Length（而不是分塊響應）是合理的，但是爲相應的HEAD請求計算Content-Length卻不合理或緩慢，是否允許HEAD迴應：

完全忽略Content-Length標頭？
迴應Transfer-Encoding: chunked即使GET迴應會有Content-Length？

relevant W3C specification的指示HEAD請求「應該」（不「必須」）具有相同的報頭進行響應;在GET響應中使用Content-Length的總體傳輸大小節省了值，在頭部的情況下值得違反前面提到的「SHOULD」，或者只有這兩個響應纔會發送Transfer-Encoding: chunked頭部信息？

來源

2015-01-09 krait

W3C規範通常不考慮競爭或其他資源限制。現實世界並不那麼寬容。國際海事組織，可以打破規範，爲最終用戶提供更好的體驗。 – pieman72 2015-01-09 23:25:33

由於從@儒略-雷什克尖端，rfc-7231表明：

服務器應該發送相同的報頭字段以響應HEAD請求，因爲這將已將如果請求一直是GET ，除了有效載荷頭域（第3.3節）可以省略。

每同一文檔的section 3.3，所述淨荷報頭字段包括：

的Content-Length
內容範圍
拖車
傳送編碼

來源

2015-01-10 03:43:10 krait

在HEAD響應中避免內容長度

回答

相關問題