如何解釋空的HTTP Accept頭？

HTTP/1.1 Accept請求標頭在RFC 2616, section 14.1中指定。如何解釋空的HTTP Accept頭？

它的語法給出這樣的：

Accept   = "Accept" ":" 
        #(media-range [ accept-params ])

#沒有任何數量根據section 2.1指出零個或多個。但是，第14.1節沒有說明如何解釋空的Accept標題。這與section 14.2相反，其中談到了Accept-Encoding，其中不僅使用1#（一個或多個），而且還指定了空頭Accept-Encoding的情況，這有點奇怪。處理請求標頭的其他部分也特定於空值的特殊情況。

如果一個同等對待的空Accept頭一個不存在Accept頭？有沒有這方面的官方資源我錯過了？

來源

2012-08-26 Jonas Wielicki

從RFC2616 Sec4.2：

每個頭字段包含一個名稱後面跟着冒號（「：」）和字段值。

乍一看，這似乎將消息指定爲格式不正確的不符合規範的類別中的空標題值。然而，在概述的增強的BNF形式表示

「#element」允許任何數目，包括零

由於這是用於指定Accept首部值的聲明，看來空值是有效的。

解析空報頭和報頭只包含空格可能是因爲從該規範以下方向的有問題的：

的場含量不包括任何前導或尾隨LWS：前線性白色空間中發生字段值的第一個非空白字符或字段值的最後一個非空白字符之後。可以在不改變字段值的語義的情況下移除這種前導或尾隨的LWS。在解釋字段值或向下遊轉發消息之前，在字段內容之間發生的任何LWS可能被替換爲單個SP。

恕我直言，發送一個空頭是完全沒有意義的。不應該這樣做，解析器可能無法正確解析這些頭文件。傳統上，誰想要避免與不符合要求的部件打交道時，這種限制人指定的「僞空」的價值觀是這樣的：

X-MyCustomHeader: ""

如果你只是想驗證一個報頭字段被一些發佈爾開關的形式，可以考慮發送一個像上面那樣的佔位符值，而不是一個空值。

更新

我想我是沒有直接回答這個問題很清楚：在一個空的接受頭的情況下，你真的有兩個選擇：

發送406 Not Acceptable響應通知客戶您不提供任何空白Accept值（duh）的內容類型。

這是合理的，但不能被RFC2616 Sec14.1必需的：

如果Accept首部字段的存在，並且如果服務器不能發送響應根據該結合接受字段值這是可以接受，那麼服務器應該發送一個406（不可接受的）響應。

或者，因爲這不是必需的，這是極不可能的用戶不接受任何內容類型（否則，他們爲什麼還要發送請求？）......我會建議處理空值Accept:值（如果消息拒絕不是選項），與Accept: */*相同。

來源

2012-08-26 16:49:38 rdlowrey

我不同意空標題格式不正確，特別是規範本身引用了空標題（請參閱我的Accept-Encoding示例）。爲了給出上下文，我正在開發python web中間件並考慮可能性以及如何對它們進行測試。我假設了''*/*''，這對我來說也是合理的。感謝您抽出寶貴的時間！ –

我也認爲''400錯誤請求'比'406不可接受'更合適，至少如果我們認爲這違反了規範。在這種情況下，我們無法弄清客戶實際接受的內容。 –

你知道，你對2616-2.1是對的 - '＃element'表單確實表明空的標題值沒問題。我將更新我的答案以反映這一點並避免錯誤信息。另外，我認爲這或者是一個406響應 - 或者將它視爲「Accept：*/*'有效。但可能不是400，因爲它在技術上不是無效的信息。 – rdlowrey

根據http://tools.ietf.org/html/rfc7231#section-5.3.2：

的請求而無需任何Accept報頭字段意味着用戶代理將接受響應中的任何介質類型。

您應該將不存在的Accept標頭視爲*/*。

來源

2016-01-04 13:14:38 cd1

是的，但你引用了一個過時的規範。目前的規格是 –

：https：//tools.ietf.org/html/rfc2616#section-14.1？ – cd1

編號RFC 2616已被RFC 7230等廢棄 –

如何解釋空的HTTP Accept頭？

回答

相關問題