[1] Set-Cookie: 欄には名前と値を =
で連結した組を ; で区切って複数記述することができます。これを
Cookieの属性といいます。
[3] 元々の Netscape の Cookie 仕様 (>>2) では最初の任意の名前と値の組 (cookie-pair) も属性と呼んでいましたが、 RFC 6265 はその後に続く cookie-av だけを属性と呼んでいます。
[378] Set-Cookie: 欄の構文は次のように定義されています。
起源鯖はこの構文に従うべきです >>377。
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-octet DQUOTE )
cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
; US-ASCII characters excluding CTLs,
; whitespace DQUOTE, comma, semicolon,
; and backslash
token = <token, defined in [RFC2616], Section 2.2>
cookie-av = expires-av / max-age-av / domain-av /
path-av / secure-av / httponly-av /
extension-av
extension-av = *<any CHAR except CTLs or ";">[5] 名前と値の組の順序については明確に規定されていませんが、 Cookie
として設定する名前と値の組 NAME=VALUE
の後に他の属性を適当な順番で記述します。
[12] 属性の名前や値の大文字と小文字を区別しないかどうかは仕様上明記されていません。 仕様書上は属性の名前はすべて小文字で記述されています。
[385] 同じ名前の属性は複数あるべきではありません。 >>377
Set-Cookie: 参照。[315] HTTP や MIME の他の頭欄では値は字句か引用文字列のいずれかとするのが一般的ですが、 Netscape Cookie では引用文字列は認められておらず、 どんな文字列であってもそのまま値としなければなりません。
[19] 仮に引用文字列を指定しても、 " は区切りではなく値の一部として認識されますし、
" で括ったとしてもその中の ; や =
は区切りとして認識されてしまいます。
[317] HTTP や MIME の他の頭欄では特定の字句の間には空白を挿入することが認められていましたが、
Netscape Cookie で認められているのかどうかは不明確です。仕様書の記述から、
「;」の直後に挿入することは認められているようです。
[16] ヘッダー全体の構文解析については、 Set-Cookie:
や Set-Cookie: を参照してください。
[329] 「※」は Set-Cookie2: 頭欄でのみ定義されていることを表します。
また、 Expires は Set-Cookie: 頭欄でのみ定義されています。
cookie-pair (NAME=VALUE)[7] Set-Cookie: 欄にはまず最初に設定する名前と値の組を属性として指定します。
この部分は cookie-pair と呼ばれています。
[4] RFC 6265 の定義では、名前は RFC 2616 の token とされています。
すなわち、 ASCII 印字可能文字を使うことができますが、一部の記号は使うことができません。
起源鯖はそれに合致しない値を使うべきではありません。 >>380
[21] 利用者エージェントは不適合な値も扱える必要があるため、
名前は (= と ; と空白以外の)
1バイト以上のバイト列として扱うことになります。
[327] 他の属性と同じ NAME を使っていいのかどうかは不明です。
[387] RFC 6265 では cookie-pair と属性は定義上別のものとされており、 特に属性の名前との衝突は禁止されていないものと思われます。
[15] RFC 6265 の定義では、値には ;, ,,
", \, 空白を含まない ASCII
印字可能文字を0文字以上続けた列か、またはそれを " で括ったものを使うことになっています。
>>380
" と \ が RFC 6265
では禁止されていて、かわりに " で括る構文が規定されています。
利用者エージェントは単に起源鯖から受け取った文字列をそのまま鯖に送り返すだけなので、
形式的に新しい構文を追加したところで互換性には影響が無いのでしょうが、
今更あえて別構文として定義する意味があるのかは疑問です。[382] 値の意味は RFC 6265 では定義しないとされています。 >>377
[383] 任意のデータを扱いたい時は、利用者エージェントとの互換性を最大化するため、 何らかの方法で値を符号化しておくことが推奨されています。 >>377
[10] その符号化の方法は具体的には規定されていませんが、 RFC 6265 では Base64 を例示しており >>377、 Netscape の仕様ではパーセント符号化を推奨 >>2 していました。
Set-Cookie:
欄に関しても何ら (利用できるのかどうかも) 定められていません。
文書の文字コードや利用者エージェントの種類によって違った解釈をされる可能性があります。
現実のCGIスクリプト等の実装は特に気にしていなかったり、
百分率符号化を用いていたりです。百分率符号化を使うのは仕様書の >>10
の記述の影響でしょうか。token、
値は token か quoted-string とされていました。
また、 RFC 2965 の Comment 属性では値は UTF-8
とされていました。 >>313, >>310[22] 利用者エージェントは不適合な値も扱える必要があるため、
値は (= と ; と空白以外の)
0バイト以上のバイト列として扱うことになります。
[388] 1つの HTTP 応答に複数個の Set-Cookie: 欄を含めることはできますが、
同じ名前の cookie-pair で複数個指定するべきではないとされています >>377。
[390] 複数の HTTP 応答によって複数の Set-Cookie:
が同時に1つの利用者エージェントに対して送り返された場合、これは競合条件であり、
結果は予測できません。 >>377
[27] 鯖が Set-Cookie: に未知の属性を指定することは構文上は認められています。
仕様上は明示的には禁止されていません。
[25] 利用者エージェントは、未知の属性を無視しなければなりません。
Set-Cookie: を参照。[26] 他の HTTPヘッダーの多くは現在では IANA登録簿が設けられていますが、
Set-Cookie: に関しては IANA登録簿がありません。
[28] 歴史的には、 Netscape Cookie に含まれなかった Max-Age
属性と HttpOnly 属性が新たに追加されています。
今後も更に属性が追加される可能性はあります。しかし大量に新たな属性が標準に追加されたり、
鯖や利用者エージェントが独自の属性を積極的に実装したりすることは当面なさそうです。