此文件為pcn-cad實驗室宋老師所指導的林昌偉、趙雪君所翻譯，如有紕漏，望大家多多指教

因特網工程任務組（IETF）

文件：6265

取代文件：2965

類別：標準化過程

ISSN：2070-1721

HTTP 狀態管理機制

摘要

本文件規定了HTTP cookie 以及Set-Cookie 頭欄位。這些頭欄位可以被HTTP伺服器用來在HTTP客戶端儲存狀態（被稱為cookie），以此讓伺服器在基本為無狀態的HTTP協議上保持有狀態會話。儘管cookies會存在安全性和私密性等歷史性的隱患，cookie 以及Set-Cookie

頭欄位在因特網上廣泛地使用。這份檔案取代RFC 2965。

這是因特網標準跟蹤文件。

這份文件是因特網工程任務組（IETF）的產物。它代表了IETF組織的共識。它接受了公共審查以及已被網際網路工作任務組（IESG）批准出版。關於網際網路標準的進一步資訊可以在RFC5741 的第二部分獲得。

本文件的當前狀態的資訊，任何勘誤表，以及如何去獲得資訊回饋可以在

版權所有（c） 2011 IETF 官方以及被確認為作者的個人，保留所有版權。

這份文件受到BCP 78 以及 IETF 官方與IETF文件相關聯的法律條款管制

自本文件的發表之日生效。請仔細閱讀這些文件，正如第四節所描述的官方法律條款描述，從該文件提取的程式碼元件必須包含簡化的BSD許可文件；並且這些程式碼被提供不包含保證，正如簡化的BSD許可文件所描述的那樣。

這份文件可能包含從IETF文件或者截止2008年11月10日可獲得的IETF公開投稿。在一些材料上的個人版權可能並沒有授予IETF官方權利在IETF標準流程以外進行修改。沒有從在這些材料上的版權個體處獲得足夠的許可，這份文件可能不能在IETF標準流程外進行修改，以及相關的衍生作品不能在IETF標準流程外進行創作，除去RFC出版的格式化需要以及將這份文件翻譯為除去英語外的其他語言。

目錄

1．簡介

這份文件定義了HTTP cookie以及Set-Cookie頭欄位。通過Set-Cookie頭欄位，HTTP伺服器可以向用戶客戶端傳遞cookie[名稱，一組值]以及相關的元資料。當用戶客戶端向伺服器發出後續請求，使用者客戶端通過元資料以及其他資訊去決定向Cookie頭部返回的名稱以及值。

儘管它們表面單一，cookies有許多複雜之處。比如說，當伺服器向客戶端傳送cookie時，顯示每一個cookie的適用範圍。這適用範圍表明使用者客戶端應該返回cookie的最長時間段，伺服器，伺服器向客戶端返回cookie的最長時間段以及可適用cookie的URI方案。

基於歷史性的原因，cookie包含很多安全以及隱私的隱患。比如說，伺服器可以表明一個給定的cookie打算“安全”連線，不打算在面對活躍的網路攻擊者時提供完整性。同樣，一個指定主機的cookie為該主機上的所有埠共享，即便是通常為網路瀏覽器所用的“同源政策”通過不同的埠隔離內容檢索。

這份詳述有兩種受眾：生成cookie的伺服器的開發者以及消耗cookie的客戶端的開發者。

為了極大化使用者客戶端的互操作性，當伺服器生成cookies時，伺服器“應該”限制到在第四部分中簡況表現良好的客戶端。

使用者客戶端“必須“新增更為書面化的在第五部分定義過的處理條例，以此去極大化在已存在在第四部分中簡況表現不良好的伺服器間的互用性。

這份文件指定了這些頭部在因特網上使用的語法和語義。特別地，除去那些目前正在使用的語法和語義，這份文件不能生成新的語法或者語義。在第四部分所提供的cookie生成的推薦展現了在現今伺服器行為下一個偏愛的子集，以及在第五部分的更為書面化的cookie處理演算法不能推薦現今所有的語法以及語義多樣性。在一些重要的方面，一些已存在的軟體不同於推薦的條款，這份文件包含了一份註解來解釋這些不同。

這份文件以前，至少存在三種cookies的解釋：所謂的“網景cookie詳述”[網景]，RFC 2109 [RFC 2109]以及RFC 2965 [RFC 2965]。然而，上述任何一個文件都沒有闡述為何cookie和cookie設定頭部確實在因特網上使用（關於歷史原因請參考[Kri 2001]）。在與以前的HTTP狀態管理機制的IETF詳述的相關關係中，這份文件請求以下行為：

1. 改變[RFC 2109]（已經為[RFC 2965]所廢止）的歷史狀態；

2. 改變[RFC 2965]的歷史狀態；

1. 表明[RFC 2965]已經被這份文件所廢止。

特別地，從歷史上移除以及廢止[RFC 2965]，這份文件反對Cookie2以及Set-Cookie2頭欄位的使用。

2．概念

2.1．適用性標準

這份文件中的關鍵詞“必須”、“必須不”、“被要求”、“將會”、“將會不”、“應該”、“應該不”、“建議”、“可能”、“可選”應該符合[RFC 2119]中的解釋。

要求闡釋在演算法的必要部分應該闡述介紹演算法中使用的關鍵字（“MUST”“MUST NOT”“REQUIRED”等）的意思。

闡釋演算法或者特定的步驟的要求一致性可以為任何行為所補充，只要最後的結果是同等。特別地，定義在這詳述的演算法應該簡單易懂，且不該是形式上的。

2.2．語法符號

這份詳述使用了擴充巴科斯-諾爾形式（ABNF）關於[RFC 5234]的註解。

接下來的核心規則為參考所包含，正如定義在[RFC 5234]，附錄B.1:

ALPHA (字母)

CR (回車)

CRLF(CR LF)

CTLs (控制字元)

DIGIT (十進位 0-9)

DQUOTE (雙引號)

HEXDIG (十六進位制0-9/A-F/a-f), LF (換行)

NUL (空八隅體)

OCTET (除去NUL的任意八位序列資料)

SP (空格鍵)

HTAB(水平製表符)

CHAR (除去NUL任何 [USASCII] 字元)

VCHAR (如何可顯[USASCII]字元)

WSP (空格).

The OWS (可選空白) 規則被用在0及其以上更多的線性空白鍵字元“可能”出現：

OWS = *( [ obs倍] WSP )

; "可選"空白

obs-fold = CRLF

OWS “應該”既不被產生或者被生成單一SP字元。

2.3．術語

術語:使用者，客戶端，委託人，伺服器，搭理人以及初始伺服器擁有與HTTP/1.1 詳述（[RFC 2616]中的第1.3部分）相同的意義。

請求主機是為使用者客戶端所知曉的主機的名稱，使用者客戶端從這裡傳送HTTP請求或者收取HTTP響應（此外，主機的名稱使得傳送相應一直的HTTP請求）。

術語請求uri定義在[RFC 2616]中的第5.1.2部分。

八隅體的兩種序列被稱為非敏感例項相互匹配當且僅當他們在i條件下等價；;ascii碼圖排序定義在 [RFC4790]。

術語流意味非NUL 八隅體的一個序列。

3．概述

這一部分概括初始伺服器給使用者客戶端傳送狀態資訊以及使用者客戶端向初始伺服器返回狀態資訊的方式。

為了儲存狀態，初始伺服器包含一個在HTTP響應中的Set-cookie頭部。在接下來的請求中，使用者客戶端向初始伺服器返回一個Cookie請求頭部。Cookie頭部包含使用者客戶端所有之前收到的Set-Cookie頭部的Cookies。初始伺服器自由地忽略Cookie頭部或者出於定義應用的目的使用內容。

初始伺服器“可能”傳送一個任意響應的Set-Cookie響應頭部。使用者客戶端“可能”忽略包含在100-層狀態碼的響應中的Set-Cookie頭部，然而“必須”處理包含在其他響應（包括400和500層狀態碼的響應）中的Set-Cookie頭部。初始伺服器可以在單個響應中包含多重Set-Cookie頭部狀態。一個Cookie或者Set-Cookie頭部狀態的顯現並不能從儲存以及反覆使用響應中排除HTTP快取。

初始伺服器“應該不”合併多重Set-Cookie 頭部狀態成一個單一的頭部狀態。通常合併HTTP頭部狀態（定義在[RFC 2616]）的機制可能會改變Set-Cookie頭部狀態的語義，因為%x2C(",")字元被Set-Cookie用來與這樣的合併競爭。

3.1．例子

使用Set-Cookie頭部，伺服器可以在HTTP響應中向用戶伺服器傳送一個短流，以至於使用者客戶端可以在未來返回在一個cookie適用範圍中的HTTP響應。比如說，伺服器可以傳送使用者客戶端帶有值31d4d96e407aad42的會話識別符號（SID）。這時，使用者客戶端在接下來的請求中返回會話識別符號。

== Server -> User Agent ==

Set-Cookie: SID=31d4d96e407aad42

== User Agent -> Server ==

Cookie: SID=31d4d96e407aad42

伺服器可以通過使用路徑以及域性質改變cookie的預設適用範圍。比如說，伺服器可以命令使用者伺服器返回example.com的每個路徑以及域。

== Server -> User Agent ==

Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=example.com

== User Agent -> Server ==

Cookie: SID=31d4d96e407aad42

正如下一個例子中所展示的，伺服器可以在使用者客戶端儲存多重cookies。比如說，伺服器可以通過返會兩個Set-Cookie頭部狀態來儲存會話識別符號和使用者偏好語言。留意到伺服器使用安全以及HttpOnly屬性為了更為敏感會話識別符號提供額外的安全保護（詳情參見4.1.2.部分）。

== Server -> User Agent ==

Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly

Set-Cookie: lang=en-US; Path=/; Domain=example.com

== User Agent -> Server ==

Cookie: SID=31d4d96e407aad42; lang=en-US

留意到上述的Cookie頭部包含兩個cookies，一個命名為SID，另一個為lang。如果伺服器希望使用者客戶端在多重會話（使用者客戶端的重啟）存留cookie，伺服器可以在過期屬性中指定過期時間。留意到如果使用者客戶端cookie儲存超過了限額或者手動刪除了伺服器的cookie，使用者客戶端可能在過期時間之前刪除cookie。

== Server -> User Agent ==

Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT

== User Agent -> Server ==

Cookie: SID=31d4d96e407aad42; lang=en-US

最後，移除cookie，伺服器返回一個帶有過去過期時間的Set-Cookie頭部。伺服器會成功地移除cookie當且僅當在Set-Cookie頭部路徑以及域屬匹配當cookie初始創造的值。

== Server -> User Agent ==

Set-Cookie: lang=; Expires=Sun, 06 Nov 1994 08:49:37 GMT

== User Agent -> Server ==

Cookie: SID=31d4d96e407aad42

4．伺服器要求

這一部分描述行為良好的Cookie以及Set-Cookie 的語法以及語義的概況。

4.1．Set-Cookie

Set-Cookie HTTP響應頭部被用來從伺服器傳送cookies到使用者客戶端。

4.1.1．語法

通常情況上，Set-Cookie響應頭部包含頭部名稱“Set-Cookie”為“：”所尾隨的cookie。每一個cookie從name-value-pair開始，為0及其以上個屬性-值對。伺服器“應該不”傳送不能遵從以下語法的Set-cookie頭部：

set-cookie-header ="Set-Cookie:" SP set-cookie-string

set-cookie-string =cookie-pair *( ";" SP cookie-av )

cookie-pair= cookie-name"=" cookie-value

cookie-name= token

cookie-value= *cookie-octet / ( DQUOTE *cookie-octetDQUOTE )

cookie-octet= %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E

; US-ASCIIcharacters excluding CTLs,

; whitespaceDQUOTE, comma, semicolon,

; and backslash

Token= <token, defined in [RFC2616], Section2.2>

cookie-av= expires-av / max-age-av / domain-av /path-av/ secure-av / httponly-av /

extension-av

expires-av= "Expires=" sane-cookie-date

sane-cookie-date = <rfc1123-date,defined in [RFC2616], Section 3.3.1>

max-age-av ="Max-Age=" non-zero-digit *DIGIT

; In practice,both expires-av and max-age-av

; are limitedto dates representable by the

; user agent.

non-zero-digit = %x31-39

; digits 1through 9

domain-av= "Domain=" domain-value

domain-value =<subdomain>

; defined in[RFC1034], Section 3.5, as

; enhanced by[RFC1123], Section 2.1

path-av= "Path=" path-value

path-value = <anyCHAR except CTLs or ";">

secure-av= "Secure"

httponly-av= "HttpOnly"

extension-av= <any CHAR except CTLs or";">

留意到以上提到的一些語法名詞參考文獻和這份文件（使用[RFC 5234]中的ABNF）不同，使用了多樣語法記法，

Cookie值的語義不是由這份文件定義的。

為了極大化使用者客戶端的相容性，希望通過一個cookie值儲存任意資料的伺服器應該編碼這份資料，比如說使用Base64[RFC4648]。

為cookie-av所產生的Set-cookie-string這部分被知曉為屬性。為了極大化客戶端的相容性，伺服器“應該不”生成同一種set-cookie-string中同種名稱下的兩種屬性（詳情請見第5.3部分中的使用者客戶端如何處理這種情形）。

伺服器“應該不”包含在同一個cookie名稱下的同一個響應的不止一個Set-Cookie頭部狀態（詳情請見第5.3部分中的使用者客戶端如何處理這種情形）。

如果一個伺服器向客戶端同時傳送包含Set-Cookie頭部的多重響應（比如說當與多個套介面的使用者客戶端交流時）這些響應生成引起不可測行為的“