在過去的十年中，HTTP社區一直忙于對Web協議現代化，對核心規范進行了多次修訂與擴展，從HTTP/2以及現在的 HTTP/3。不幸的是，從最初到現在我們定義和使用HTTP header的方式并沒有什么大的改變，由于未指定的Headers（以及處理方式的多樣性）引起的互通性問題，為開發人員帶來很多痛苦，甚至引發安全問題。

●HTTP標頭有什么問題？●

大多數Web開發人員都熟悉HTTP標頭；如Content-Length、Cache-Control和Cookie之類。它們會攜帶請求和響應的元數據，通常，這部分數據是消息發送者由于某種原因無法放入正文內容的信息，或者是消息接收者無需查看正文內容即可獲得的信息。 因為標頭需要由許多不同的客戶端和服務器，代理服務和CDN處理（通常在消息的生存期內不止一次），所以大家希望它們易于處理，高效解析并且定義明確句法。 HTTP將頭值（更恰當的說是字段值，因為它們也可能出現在主體后面的尾部字段中)定義為一個約束很少的“八進制序列”(即字節），盡管建議是ASCII字節。它還建議在ABNF中定義標題，如果用逗號分隔字段的值，則可以將同名的多個字段組合在同一行上。 因此，每個標題字段都有自己的唯一定義，需要知道它才能解析值。一些領域作者使用ABNF來做到這一點；另一些人使用示例。有些只是讓你根據你以前看到的價值觀來猜測。 例如，考慮年齡年限標題。它是核心HTTP規范的一部分，所以它應該是定義明確的，而且它只是一個簡單的整數。

Age: 42

由此ABNF指定:

Age = delta-secondsdelta-seconds = 1*DIGITDIGIT = %x30-39 ; 0-9

起初這似乎很簡單——0到9之間數字的一個到多個實例。但在實際考慮中，如果一個實現遇到這些現實標題中的任何一個，它應該做什么：

Age: 0, 60Age: 60, 0Age: 50mAge: abc234Age: 60;ms=212

它不是那么簡單，因為測試真正的緩存需要用年限顯示。 因此，當同一個人正在編寫生成和消耗消息頭的代碼而沒有其他人時，示例或ABNF可能是一個足夠的定義，但如果有多個實現生成和解析值，則互操作性是很糟的。 每個標題作者都必須記住要解決一個問題列表，這些問題涉及如何處理重復值、案例規范化、無論是單個項目還是列表等等。通常，他們不會處理這些問題，這意味著開發者通常以不同的方式自行選擇。 未充分指定的消息頭也是安全問題的來源；如果實現解析消息頭的方式不同，它們的行為可能會不同，從而導致Response Splitting這類的攻擊。 瀏覽器供應商已經足夠關注這些問題，開始像CSP算法那樣定義頭。也就是說，他們費力地定義解析和序列化算法，然后創建測試用例。這種方法對字段語法的模糊性較小，實現之間的差異較小。然而，它仍然是一次性的；它只有助于澄清特定標題的算法。對于規范的作者來說，去努力并確保它是正確的也是很累的-所以大多數標題作者都不會費心。它還為實現者創建了大量繁忙的工作，因為他們需要分別實現每個新的頭的解析器。

●引入結構化領域●

HTTP工作組已經非常清楚了這類問題，幾年前我們開始嘗試定義一些更好的方法，使人們可以使用這些東西來創建新的字段。經過幾次嘗試后，我們確定了一種最初稱為結構化標題的方法，但我們現在（更正確地）稱之為“結構化字段”。 結構化字段是一個定義良好的數據類型庫，在HTTP頭和拖車中可能有用，包括字符串、Tokens、布爾值、整數、小數和字節序列作為原子“Item”類型，以及這些項的列表和字典。重要的是，它定義了每種類型的精確解析和序列化算法，以及錯誤處理和詳細的測試套件-所有這些都有助于確保互操作性。 這允許新頭字段的作者根據這些類型定義它。例如，他們可以說“這是一個字符串列表”，人們將知道如何使用一個現成的庫來明確地解析和生成標頭，而不是編寫特定于頭的代碼。

Example-Header: "blue", "sort of red", "green"每個項目也可以有參數，或鍵/值對的額外信息。參數是一種重要的可擴展性機制，它允許消息頭隨著時間的推移而演變。

Example-Header: "blue"; websafe, "sort of red"; author="sue", "green"

遞歸的形式也很有限；列表和字典值也可以包含列表，例如：

Example-Header: people=(joanna stacy), places=("new york" "rome") 內部列表中的每個項目以及內部列表本身都可以進行參數化。 你可能會注意到，這些消息頭看起來很像許多現有的HTTP字段。這是通過設計實現的；不僅對開發人員來說是舒適的，它還允許通過結構化字段實現生成許多現有字段，并且通常它們也可以被解析。例如，許多Cache-Control報頭都是有效的“結構化字段”，即使它沒有定義為一個：

Cache-Control: max-age=3600, immutable

很不幸你還不能將結構化字段用于現有的標頭，也無法僅通過查看它來判斷給定字段是否是結構化字段；你必須知道它的定義值，因為結構化字段至少在現在才用于新字段。

●使用結構化字段獲得更好的性能●

指定新字段更容易，并使它們更安全和更可互操作，這對HTTP來說是一個顯著的改進。如果結構化字段也能幫助HTTP性能呢？他們有兩種方法可以幫助你。顯然，這些都是投機性的好處，但它們仍然是有趣的談論。 首先是解析效率。由于傳統的HTTP消息頭是文本形式的，解析器必須接觸字符串中的每個字節，有時需要多次，有時會將其復制并重新復制到內存的不同部分。這是一個固有的低效過程，HTTP/2和HTTP/3是二進制協議而不是文本協議的原因之一。 在結構化字段之前，我們對此無能為力，因為HTTP消息頭的定義非常松散。結構化字段中定義良好的數據類型會改變這一點。現在，我們可以定義一個新的，二進制序列化的任何頭使用他們。 二元結構化字段是定義這種序列化的草案建議，以定義這樣的序列化。它使用HTTP/2（和/3）SETTINGS機制來協商對替代序列化的支持，并利用結構化字段與許多現有標題字段的語法的相似性將其返回到一組已經廣泛使用的標題字段上，如果它們無法解析，則返回到不透明的文本。 二進制序列化將幫助性能多少？由于預期會減少CPU負載，因此它應該減少請求處理的延遲并提高可伸縮性。我們還沒有真實的統計，但是如果你考慮許多標題所采取的路徑-從JavaScript到瀏覽器，然后再到CDN，通過多個CDN節點到源服務器，再到應用程序代碼本身。累積節省的潛力是有吸引力的。 結構化字段可能有助于性能的第二種方法是通過提高壓縮效。HTTP/2為頭和拖車字段引入了HPACK壓縮。雖然它的前身SPDY使用GZIP，但由于CRIME攻擊，它被發現是不安全的。因此，HPACK(及其繼承者QPACK)通過引用整個字段值來壓縮字段；如果它的任何一部分發生變化，它就不能使用以前的引用（有時會對壓縮效率產生令人驚人的影響）。 之所以選擇整值粒度，是因為通用解析器無法理解字段值的結構；為了安全起見，我們必須確保攻擊者無法通過猜測部分字段值來探測加密。 對于結構化字段，現在有一種潛在的方法可以使壓縮算法對字段中的單個數據類型而不是整個值進行操作。

Cache-Control: max-age=3600, s-maxage=7200, must-revalidate

例如，考慮以下Cache-Control字段： 使用HPACK和QPACK，整個字段值存儲在動態表中，并且只能由具有完全相同值的未來消息引用。如果我們將其解析為結構化字段并存儲單個數據類型，我們可以存儲：

lmax-age

l3600

ls-maxage

l7200

lmust-revalidate

這些變量中的每一個都可以在將來的標頭中出現時分別引用，從而使壓縮算法更精細，而且效率更高。 早期的原型表明，使用這種技術的提升對于Web瀏覽器連接來說效率非常低的，因為它們的標題往往是高度重復的，用多個字節（字段值中的每種類型都有一個字節）替換HPACK中的1字節引用實際上會造成傷害。 對于從多個客戶端攜帶流量的連接——例如反向代理和源服務器上游的CDN所看到的流量——好處可能更明顯；需要更多的實驗。

●長期改善HTTP●

如果上面描述的反向導入技術被捕獲，未來版本的HTTP(或HTTP/2和HTTP/3的擴展)可以大大減少使用中的非結構化消息頭的數量。 二進制結構化字段草案描述了兩種實現方法。如果字段的語法與結構化字段兼容-至少在大多數情況下-它可以作為一個發送，當失敗時返回到明文標題。 沒有兼容語法的標題需要另一種方法。例如，Date、Last-Modified、Expires和類似的消息頭永遠不可能是有效的結構化字段。但是，可以將日期表示為整數，結構化字段可以傳遞整數。 所以，就有這樣的標題：

Date: Thu, 09 Apr 2020 09:06:50 GMT

可能會在適當的轉譯跳點上表示為：

SF-Date: 1586423210

這為我們提供了一種方法，可以將所有通用消息頭和額外的元信息作為結構化字段發送。

●立即使用結構化字段●

結構化字段規范正處于標準化的最后階段，這意味著它很快會成為一個RFC。目前我們已經有多個實例，包括在Chrome中，許多新的安全頭(例如Fetch元數據)都是結構化的。 同時，可以通過具體實現來了解它們是如何工作的。例如，Python http_sfv庫允許從命令行解析它們。 如果你定義了新的消息頭（無論它們是針對整個的Web還是僅針對HTTP API）都可以在RFC發布后開始使用結構化字段。