http-headers header教學 - 自定義HTTP標頭:命名約定





header分析 header限制 (5)


HTTP標頭的格式在HTTP規範中定義。 我將討論HTTP 1.1,規範是RFC 2616 。 在第4.2節“消息標題”中,定義了標題的一般結構:

   message-header = field-name ":" [ field-value ]
   field-name     = token
   field-value    = *( field-content | LWS )
   field-content  = <the OCTETs making up the field-value
                    and consisting of either *TEXT or combinations
                    of token, separators, and quoted-string>

這個定義取決於兩個主要支柱,即令牌和TEXT。 兩者在第2.2節“基本規則”中都有定義。 令牌是:

   token          = 1*<any CHAR except CTLs or separators>

依靠CHAR,CTL和分離器:

   CHAR           = <any US-ASCII character (octets 0 - 127)>

   CTL            = <any US-ASCII control character
                    (octets 0 - 31) and DEL (127)>

   separators     = "(" | ")" | "<" | ">" | "@"
                  | "," | ";" | ":" | "\" | <">
                  | "/" | "[" | "]" | "?" | "="
                  | "{" | "}" | SP | HT

TEXT是:

   TEXT           = <any OCTET except CTLs,
                    but including LWS>

LWS是線性空白空間,其定義我不會再現,而OCTET是:

   OCTET          = <any 8-bit sequence of data>

這個定義附有一個說明:

The TEXT rule is only used for descriptive field contents and values
that are not intended to be interpreted by the message parser. Words
of *TEXT MAY contain characters from character sets other than ISO-
8859-1 [22] only when encoded according to the rules of RFC 2047
[14].

所以,有兩個結論。 首先,很明顯,標題名稱必須由ASCII字符的子集組成 - 字母數字,一些標點符號,而不是其他標點符號。 其次,標題的定義中沒有任何內容將其限制為ASCII或排除8位字符:它明確由八位字節組成,只有控製字符被禁止(注意CR和LF被認為是控制)。 此外,關於TEXT製作的評論意味著八位字節將被解釋為ISO-8859-1,並且存在用於表示編碼之外的字符的編碼機制(這是可怕的,偶然)。

所以,要特別回應@BalusC,很明顯根據規範,標題值在ISO-8859-1中。 我在Tomcat的頭文件中發送了高8859-1個字符(特別是一些法語中使用的重音元音),並且他們已經通過Firefox正確解釋了它們,因此在某種程度上,這在實踐中以及在理論上起作用(儘管這是一個位置標題,它包含一個URL,而這些字符在URL中是不合法的,所以這實際上是非法的,但根據不同的規則!)。

也就是說,我不會依賴ISO-8859-1在所有服務器,代理和客戶端上工作,所以我會堅持使用ASCII作為防禦性編程。

我們的一些用戶要求我們在其發送的請求的HTTP標頭中包含與其帳戶相關的數據,甚至包括從我們的API獲得的響應。 在命名格式等方面添加自定義HTTP標頭的一般慣例是什麼?

另外,請隨時發布您在網絡上偶然發現的任何巧妙用法; 我們正在嘗試使用最好的方式來實現這個目標:)




標頭字段名稱註冊表在RFC3864定義,沒有什麼特別的“X-”。

據我所知,沒有私人標題的指導原則; 如有疑問,請避開它們。 或者看看HTTP Extension Framework( RFC 2774 )。

了解更多的用例會很有趣。 為什麼不能將信息添加到消息正文中?




2012年6月,建議使用“X-”前綴的做法已經正式成為RFC 6648 。 以下是相關信息:

3.對新參數創建者的建議

...

  1. 不應該用“X-”或類似的結構來為它們的參數名加前綴。

4.對議定書設計者的建議

...

  1. 不應該禁止帶有“X-”前綴或類似構造的參數被註冊。

  2. 不得規定具有“X-”前綴或類似結構的參數需要被理解為非標準化。

  3. 不得規定沒有“X-”前綴或類似結構的參數需要被理解為標準化。

請注意,“不應該”(“不鼓勵”)與“禁止”(“禁止”)不同,另請參閱RFC 2119關於這些關鍵字的其他規範。 換句話說,您可以繼續使用“X-”前綴標題,但不推薦使用,並且您不能將它們記錄為公共標準。

2011年6月,發布了第一份IETF草案 ,以反對對非標準標題使用“X-”前綴的建議。 原因是,當以“X-”為前綴的非標準頭文件變為標準時,刪除“X-”前綴會破壞向後兼容性,迫使應用程序協議同時支持兩個名稱(例如, x-gzipgzip現在等同)。 所以,建議只是在沒有“X-”前綴的情況下對其進行合理命名。

建議是以 “X-”開始他們的名字。 例如X-Forwarded-ForX-Requested-With 。 這也在RFC 2047的第5節中提到。




這個問題需要重新閱讀。 被問到的實際問題與CSS屬性中的供應商前綴不相似,在這些前提下,供應商支持和官方標準的未來驗證和考慮是適當的。 問的實際問題更類似於選擇URL查詢參數名稱。 沒有人應該關心他們是什麼。 但是,定制名稱間隔是完全有效的,也是常見的,正確的做法。

理由:
它是關於開發人員為定制的,特定於應用程序的頭文件而製定的慣例 - “ 與其帳戶相關的數據 ” - 與供應商,標準組織或由第三方實施的協議無關,除了所涉及的開發人員只需避免服務器,代理或客戶端可能有其他預期使用的標頭名稱。 出於這個原因,給出的“X-Gzip / Gzip”和“X-Forwarded-For / Forwarded-For”示例是沒有意義的。 提出的問題是關於私有API上下文中的約定,類似於URL查詢參數命名約定。 這是一個偏好和名稱空間的問題; 任何沒有“X”的代理或供應商都支持“X-ClientDataFoo”的擔憂顯然是錯誤的。

關於“X-”前綴沒有什麼特別的或神奇的,但它有助於明確它是一個自定義標題。 實際上,RFC-6648等人幫助支持使用“X-”前綴的情況,因為 - 作為HTTP客戶端和服務器的供應商放棄前綴 - 您的應用特定的私有API,個人數據 - 傳遞機制變得更好 - 與少量官方保留標題名稱的名稱空間衝突隔離。 也就是說,我的個人偏好和建議是更進一步,例如“X-ACME-ClientDataFoo”(如果你的小部件公司是“ACME”)。

恕我直言,IETF規範並沒有充分具體地回答OP的問題,因為它無法區分完全不同的用例:(A)供應商一方面引入了新的全球適用功能,如“Forwarded-For”,另一方面與(B)應用程序開發人員將應用程序特定的字符串傳遞給客戶端和服務 (A)。規範只關注前者。 這裡的問題是(B)是否有公約。 有。 它們涉及將參數按字母順序分組在一起,並將它們與類型(A)的許多與標準相關的標題分開。 (B)使用“X-”或“X-ACME-”前綴方便且合法,並且與(A)不衝突。 (A)中停止使用“X-”的廠商越多,(B)將變得越清晰。

例:
谷歌(在各種標準組織中佔有一席之地)是 - 截至今天,20141102在我的回答中進行了輕微的修改 - 目前使用“X-Mod-Pagespeed”來表示他們所涉及的Apache模塊的版本轉換給定的響應。 有人真的建議谷歌應該使用“Mod-Pagespeed”,沒有“X-”,和/或要求IETF保佑它的使用?

概要:
如果您在您的應用程序中使用自定義HTTP標頭(作為Cookie的一種有時適合的替代方法)以將數據傳遞到服務器或從您的服務器傳遞數據,並且這些標頭顯然不是意圖在應用程序的上下文之外使用,名稱 - 將它們與“X-”或“X-FOO-”前綴隔開是一個合理且常見的約定。




如果你想發送你的自定義標題 ,你可以這樣做:

curl -v -H @{'custom_header'='custom_header_value'} http://localhost:3000/action?result1=gh&result2=ghk




http http-headers