這個問題值得重讀.實際問到的問題與css屬性中的供應商前綴不類似，因為將來的驗證和考慮供應商支持和官方標準是合適的。實際詢問的問題更類似于選擇URL查詢參數名稱。沒有人應該在乎他們是什么。但是自定義的名字間距是完全有效的-而且很常見，而且是正確的-這是要做的事情。
理由：
是關于開發人員之間關于自定義、特定于應用程序的標頭的約定 -- "與其賬戶有關的數據“-與供應商、標準機構或由第三方實施的協議無關，只是有關開發人員只需避免可能由服務器、代理或客戶端使用的標頭名稱。出于這個原因，“X-Gzip/Gzip”和“X轉發-轉發/轉發-為”的例子是沒有意義的。提出的問題是私有API上下文中的約定，類似于URL查詢參數命名約定。這是一個偏好和名稱間隔的問題；任何代理或供應商支持“X-ClientDataFoo”而不使用“X”顯然是錯誤的。
沒有什么特別或神奇的“X-”前綴，但它有助于明確它是一個自定義頭。事實上，RFC-6648等人幫助支持使用“X-”前綴的理由，因為-由于HTTP客戶端和服務器的供應商放棄了前綴-您的應用程序專用的、私有的API，個人數據傳遞機制正在變得更好地抵御名稱空間與少量官方保留的標頭名稱的沖突。盡管如此，我個人的偏好和建議是更進一步。“X-ACME-ClientDataFoo”(如果您的小部件公司是“ACME”)。
IMHO IETF規范不夠具體，無法回答OP的問題，因為它未能區分完全不同的用例：(A)供應商引入了新的、適用于全球的特性，例如“轉發-for”。(B)應用程序開發人員向客戶端和服務器傳遞特定于應用程序的字符串。規范只涉及前者，(A)。這里的問題是，是否有(B)項的公約。確實有。它們涉及按字母順序將參數組合在一起，并將它們與許多標準相關的類型(A)標頭分開。使用“X-”或“X-ACME-”前綴是方便和合法的(B)，不與(A)沖突。供應商停止使用“X-”(A)的次數越多，(B)就會變得越清晰。
例子：
谷歌(在不同的標準體系中有一定的分量)-到今天為止，在我的回答中有20141102個-目前正在使用“X-Mod-Pagspeed”來表示他們的Apache模塊在轉換給定的響應時所使用的版本。有人真的建議谷歌不要使用“X-”，而應該使用“Mod-Pagspeed”，或者讓IETF來祝福它的使用嗎？
摘要：
如果您在應用程序中使用自定義HTTP標頭(有時是Cookie的適當替代)將數據傳遞到或從您的服務器傳遞，并且這些標頭明確地、不打算在應用程序上下文之外使用，則可以使用“X-”或“X-foo-”前綴來命名它們，這是一種合理的、常見的約定。
