構文
[378] Set-Cookie: 欄の構文は次のように定義されています。
起源鯖はこの構文に従うべきです >>377。
[379] なぜか違反を完全に禁止はされていません...[380] RFC 6265 >>377, >>24 による 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
の後に他の属性を適当な順番で記述します。
[325] RFC 2109, RFC 2965 では NAME=VALUE
の後に他の属性が来ること、他の属性の順序は任意であることが明記されていました。
>>324, >>323[326] 属性の名前が同じものが複数回使われている場合の解釈については触れられていません。
[327] RFC 2109 ではその場合の動作は未定義とされていました >>324。
RFC 2965 では最初に現れたものが有効であるとされていました >>323。大文字と小文字
[12] 属性の名前や値の大文字と小文字を区別しないかどうかは仕様上明記されていません。
仕様書上は属性の名前はすべて小文字で記述されています。
[314] RFC 2109, RFC 2965 では名前の大文字と小文字を区別しないとされていました。
>>313, >>310重複
[385] 同じ名前の属性は複数あるべきではありません。 >>377
[386] なぜか完全に禁止はされていません。[18] 複数指定された場合、最後の属性が採用されます。
Set-Cookie: 参照。引用文字列
[315] HTTP や MIME の他の頭欄では値は字句か引用文字列のいずれかとするのが一般的ですが、
Netscape Cookie では引用文字列は認められておらず、
どんな文字列であってもそのまま値としなければなりません。
[316] RFC 2109, RFC 2965 では値は字句または引用文字列とされていました。
>>313, >>310[19] 仮に引用文字列を指定しても、 " は区切りではなく値の一部として認識されますし、
" で括ったとしてもその中の ; や =
は区切りとして認識されてしまいます。
空白
[317] HTTP や MIME の他の頭欄では特定の字句の間には空白を挿入することが認められていましたが、
Netscape Cookie で認められているのかどうかは不明確です。仕様書の記述から、
「;」の直後に挿入することは認められているようです。
[316] RFC 2109, RFC 2965 では字句の間に空白を入れてもよいとされていました。
>>313, >>310[20] RFC 6265 では ; の直後に1つだけ SPACE
を書かなければならないと明確化されました。
cookie-pair (NAME=VALUE)
[7] Set-Cookie: 欄にはまず最初に設定する名前と値の組を属性として指定します。
この部分は cookie-pair と呼ばれています。
[8] この属性は必須です。 >>2, >>380
名前
[4] RFC 6265 の定義では、名前は RFC 2616 の token とされています。
すなわち、 ASCII 印字可能文字を使うことができますが、一部の記号は使うことができません。
起源鯖はそれに合致しない値を使うべきではありません。 >>380
[14] Netscape の定義では ;, ,,
空白 を除く任意の値とされており >>2、それよりずっと厳しくなっています。[21] 利用者エージェントは不適合な値も扱える必要があるため、
名前は (= と ; と空白以外の)
1バイト以上のバイト列として扱うことになります。
予約名
[327] 他の属性と同じ NAME を使っていいのかどうかは不明です。
[387] RFC 6265 では cookie-pair と属性は定義上別のものとされており、
特に属性の名前との衝突は禁止されていないものと思われます。
[328] RFC 2109 でも明記されていませんでした。
RFC 2965 では属性の名前と同じ NAME を使って構いません。
>>323[325] RFC 2109, RFC 2965 では $
から始まる名前は予約となっており、
応用が使ってはならないとされていました。
>>324, >>323 (Cookie: 頭欄で $
は特別な属性を表すために使われていました。)値
[15] RFC 6265 の定義では、値には ;, ,,
", \, 空白を含まない ASCII
印字可能文字を0文字以上続けた列か、またはそれを " で括ったものを使うことになっています。
>>380
[9] Netscape の元々の定義では、値は任意の値ですが、 ;, ,,
空白は使えないとされていました。 >>2[381] それまで使えていた " と \ が RFC 6265
では禁止されていて、かわりに " で括る構文が規定されています。
利用者エージェントは単に起源鯖から受け取った文字列をそのまま鯖に送り返すだけなので、
形式的に新しい構文を追加したところで互換性には影響が無いのでしょうが、
今更あえて別構文として定義する意味があるのかは疑問です。[382] 値の意味は RFC 6265 では定義しないとされています。 >>377
[383] 任意のデータを扱いたい時は、利用者エージェントとの互換性を最大化するため、
何らかの方法で値を符号化しておくことが推奨されています。 >>377
[10] その符号化の方法は具体的には規定されていませんが、 RFC 6265 では Base64
を例示しており >>377、 Netscape の仕様ではパーセント符号化を推奨
>>2 していました。
[384] このため CGI などで Cookie を扱うライブラリーの類では Cookie
の値をパーセント符号化、パーセント復号する実装になっていることもよくあります。[11] Netscape の仕様上は >>9 の記号類以外の任意の文字が使えることになっていますが、その「文字」
全体の集合が何かは不明です。HTTP
頭部で非ASCII文字を使う方法は標準不在な状況で、Set-Cookie:
欄に関しても何ら (利用できるのかどうかも) 定められていません。
文書の文字コードや利用者エージェントの種類によって違った解釈をされる可能性があります。
現実のCGIスクリプト等の実装は特に気にしていなかったり、
百分率符号化を用いていたりです。百分率符号化を使うのは仕様書の >>10
の記述の影響でしょうか。[13] = も名前か値かその両方かで使えないはずなのですが、
Netscape の仕様上は明記されていませんでした。 RFC 6265 によれば名前の方で使えなく、
値には使うことができます。[348] RFC 2109 や RFC 2965 では名前は token、
値は token か quoted-string とされていました。
また、 RFC 2965 の Comment 属性では値は UTF-8
とされていました。 >>313, >>310[22] 利用者エージェントは不適合な値も扱える必要があるため、
値は (= と ; と空白以外の)
0バイト以上のバイト列として扱うことになります。
重複の扱い
[388] 1つの HTTP 応答に複数個の Set-Cookie: 欄を含めることはできますが、
同じ名前の cookie-pair で複数個指定するべきではないとされています >>377。
[389] Netscape の仕様では、その場合どれが採用されるのか明記されていませんでした。[390] 複数の HTTP 応答によって複数の Set-Cookie:
が同時に1つの利用者エージェントに対して送り返された場合、これは競合条件であり、
結果は予測できません。 >>377
サイズ制限
[23] Cookieのサイズ制限参照。未知の属性
[27] 鯖が Set-Cookie: に未知の属性を指定することは構文上は認められています。
仕様上は明示的には禁止されていません。
[25] 利用者エージェントは、未知の属性を無視しなければなりません。
Set-Cookie: を参照。[342] 未知の属性の扱いは RFC 2109 では明確には規定されていませんでしたが、 RFC 2965
では利用者エージェントは未知の属性を無視しなければなりませんとされていました
>>341。[26] 他の HTTPヘッダーの多くは現在では IANA登録簿が設けられていますが、
Set-Cookie: に関しては IANA登録簿がありません。
[28] 歴史的には、 Netscape Cookie に含まれなかった Max-Age
属性と HttpOnly 属性が新たに追加されています。
今後も更に属性が追加される可能性はあります。しかし大量に新たな属性が標準に追加されたり、
鯖や利用者エージェントが独自の属性を積極的に実装したりすることは当面なさそうです。