[1] Cookie: ヘッダーは、
利用者エージェントに保存されているクッキーを示します。
[65] Cookie: ヘッダーの値は、 cookie-string です。
RFC 6265
[101] cookie-string は、
1個以上の cookie-pair の列です。cookie-pair 間には
; と SP の2文字の列が必要です。 RFC 6265
[66] 鯖が RFC 6265 に適合する Set-Cookie: 欄を送信し、
利用者エージェントが RFC 6265 に適合する処理を行った場合、
鯖は >>65 の構文に適合する Cookie: 欄を受け取るはずです >>64。
[67] ここで cookie-pair は鯖が送信し、利用者エージェントが蓄積していたものをそれぞれ表しています。
それぞれの名前と値の意味は RFC 6265 では定義しておらず、当該アプリケーションにおける意味に従って処理されるべきものです。
Set-Cookie: 時に指定した属性は Cookie:
には含まれておらず、どの Path に対して発行したものなのか、などを
Cookie: だけから判定することはできません。 >>64
[70] しかし実際には鯖も利用者エージェントも RFC 6265 に適合するとは限りません。
利用者エージェントが RFC 6265 に従って Set-Cookie: 欄を構文解析していると仮定すると、
クッキーの名前や値は token で認められない文字を含むことがあります。
先頭と末尾が空白ではなく、 ; と =
を含まない任意の1文字以上の文字列が名前となり得ます。また値は先頭と末尾が空白ではなく、
; を含まない任意の0文字以上の文字列となります。
[75] 利用者エージェントは、蓄積されているクッキーがあれば
Cookie: ヘッダーを要求に含めます >>24。
[5] 利用者エージェントは、 HTTP/1.1 以下の要求で複数の
Cookie: ヘッダーを生成してはなりません >>24。
,
で連結しても等価とされていますが、クッキーの名前や値に ,
が含まれる可能性があり、これが成立しません。 (RFC 6265 の構文は ,
を名前や値に認めていないので、適合する鯖が発行したクッキーなら曖昧性はありませんが、
そうでないものを鯖側で処理する可能性を想定するのであれば、 ,
で結合・分割できません。)[103] HTTP/2 では、1つ以上の cookie-pair が値となる
Cookie: ヘッダー複数個に分割して含めても構いません >>100。
[76] しかし利用者エージェントは Cookie:
ヘッダーを省略しても構いません >>24。
[94] 利用者エージェントは、クッキーが無効に設定されている時、
Cookie: ヘッダーを要求に含めてはなりません >>93。
[99] WebSocket handshake でも使うことができます。
[110]
cookie-string は、
curl
の
--cookie
でも使われます。
[78] 利用者エージェントは、次の条件をすべて満たすクッキーを使って
Cookie: ヘッダーを生成しなければなりません >>24。
[74] 利用者エージェントは、 Cookie:
ヘッダーを生成する際にクッキーを次のように整列するべきです
>>24。
Set-Cookie: 参照)。[87] 利用者エージェントは、>>78 で得られたクッキーを >>74
で整列し、 ; と SPACE の列で区切って連結したものを
Cookie: ヘッダーとして使わなければなりません。ただし、
各クッキーは名前と値を = で連結したものとしなければなりません。
>>24
Cookie: ヘッダーの構文に適合しない結果になることもあります。[88] また利用者エージェントは >>78 で得られたクッキーの最終アクセス時刻を現在日時に設定しなければなりません >>24。
[63] 起源鯖は Cookie: 欄やその中身を無視して構いません。 >>61
[68] クッキーは順番に並べることになってはいますが、鯖ではそれに依存するべきではありません。 特に、同じ名前のクッキーが複数ある場合に、これがどの順番で現れるかに依存するべきではありません。 >>64
Set-Cookie:
ヘッダーの構文解析を詳細に規定しているのに対して) 起源鯖による
Cookie: ヘッダーの構文解析の方法を詳細には規定していません。
鯖が適合する Set-Cookie: ヘッダーを出力し、
利用者エージェントが適合する方法で処理する限り、
Cookie: ヘッダーの値は常に ABNF
構文に適合するはずなので、それ以上に構文解析法を規定する必要もないのかもしれません。
あるいは鯖が内部でどのようにヘッダーの値を解釈するかは鯖側の著者 (開発者)
以外には観測できず、適合性を議論するのが難しいという事情もあるかもしれません。Cookie:
ヘッダーを送信してきた場合にも (エラーを返すなど) 適当な処理を行えなければなりません。
Webブラウザー以外から適合しない Cookie:
ヘッダーが送られたり、 Webブラウザーからも (著者のミスや悪意ある利用者により)
適合しない Cookie: ヘッダーが送られたりする可能性は排除できません。
またライブラリーの類は、Webアプリケーションの開発者が不適合な
Set-Cookie: ヘッダーを送信している可能性を排除できませんから、
不適合な Cookie: ヘッダーであってもできるだけ“正しく”
処理できることが求められます。[102] HTTP/1.1 以下で Cookie: ヘッダーが複数ある場合にどう処理するべきかは不明です。
, はヘッダーの連結ではなく、名前や値の一部と常に仮定していいかもしれません。[105] HTTP/2 で複数の Cookie: ヘッダーがある場合、
HTTP/1.1 接続や汎用 HTTP サーバー応用など HTTP/2
以外へと引き渡される時は、 ; と SP
の列によって連結して1つにしなければなりません >>100。
[62] Cookie: 欄の有無はキャッシュ可能性に影響しません >>61。
[10] 串は Cookie: をそのまま鯖へと転送するべきです。
それがたとえ If-Modified-Since: つきの条件付き要求であってもです。
>>2
When requesting a URL from an HTTP server, the browser will match the URL against all cookies and if any of them match, a line containing the name/value pairs of all matching cookies will be included in the HTTP request. Here is the format of that line:
Cookie: NAME1=OPAQUE_STRING1; NAME2=OPAQUE_STRING2 ...
[4] HTTP 要求を構築する際に、要求URL と利用者エージェントが保持している Cookie
を比較し、一致するものであれば Cookie: 要求頭欄に入れます。
Cookie: 欄には Cookie の名前と値の組を
Cookie: NAME1=OPAQUE_STRING1; NAME2=OPAQUE_STRING2 ...のように並べて記述します。 >>2
[7] 同じ名前の値は、Domain や Path
が同じなら設定時に古いものが上書きされますが、
違っていれば両方共残ります。その場合には Cookie:
頭欄にも両方共含められます。 >>2
[9] より具体的な Path の Cookie はより一般的な Path
の Cookie よりも先にくるべきです。例えば a=1; path=/foo と
b=2; path=/foo/bar があれば、 b=2; a=1
のように送るべきです。 >>2
[8] 同じ Path の時の名前と値の組の順序は明確に規定されていません。
[69] CGI::Cookie ( 版) http://cpansearch.perl.org/src/MARKSTOS/CGI.pm-3.59/lib/CGI/Cookie.pm
は、古い Netscape が複数の同じ名前のクッキーを送ることがあり、一番前のものが最新であるとしてそれを使っています。
Cookie: 頭欄の定義[19] RFC 2109, RFC 2965 では Netscape Cookie とはあまり互換性がない
Cookie: 頭欄が定義されていました >>17, >>18。
概要:
token、値は token
または quoted-string でなければなりません >>17, >>18。$Version=1 のように指定することになっていました >>17, >>18。$Version には送信する Cookie に対応する
Set-Cookie、Set-Cookie2 の Version と同じものを指定することになっていました。それがない時は 0 を使うことになっていました >>17, >>18。Set-Cookie, Set-Cookie2 のどちらも
Version は 1 で区別できませんが、それでいいのでしょうか。。。Set-Cookie2 は Version
が必須のはずですが、ない時の規定が残っているのは消し忘れでしょうか。。。; $Path=... のように属性を指定することになっていました
>>17, >>18。$Path >>17, >>18,
$Domain >>17, >>18,
$Port >>18 がありました。Set-Cookie, Set-Cookie2 に
Path, Domain, Port
各属性があった場合は同じ値 (または同じように値なし) でなければなりませんでした
>>17, >>18。属性自体がなかった場合には $Path,
$Domain は省略するべき >>17, >>18、 $Port
は省略しなければならない >>18 とされていました。Path がより具体的なものほど前に来る
>>17, >>18 とされていました。; とされていました。
一方で将来との互換性のため鯖は , も受け付けなければならないとされていて、
ABNF 構文上もそうなっていました。 >>17, >>18$ からはじまる名前を特別な意味を持つものとして解釈するべきです
>>36, >>37 とされていました。$ 付きの属性は、前から順に調べていって、一番最初の $ 無しの属性の手前までは全体に適用される属性、その後は直前の $ 無しの属性に適用される属性と解釈するとされていました >>36。Cookie: を応答に付け足してはなりません
>>42, >>43。[46] Netscape Cookie の互換性について、次のようなことが言われていました >>45。
Cookie: を送る$]」で始まる属性をそういう Cookie だと思って無視する$Version」の有無で新旧クライアントを区別できる[52] >>46 を読むと一見後方互換性が保たれていると錯覚してしまいがちですが、 新 Cookie では属性の値が引用文字列でもあり得るので、 旧クライアント・旧鯖は引用符も値の一部だと思ってしまうという問題があります。
[56] >>48 より新クライアントは常に新 Cookie を送ることになっているので、 常に引用文字列で送る新クライアントは旧鯖とは正しくやり取りできなくなり、 >>55 のような注意が必要になるわけです。でも >>54 のように注意しろと言われても困った話です。 引用符が必要な値だけど引用符を使えないときは引用符を外していいのでしょうか。 でも外すと RFC 2109 には適合しなくなります。
[57] また、 RFC 2109 は「=」の周りの空白についても、
Netscape Cookie では認められていなかったので注意するよう書いています >>53。
[58] Mojo::Cookie::Request - search.cpan.org ( 版) http://search.cpan.org/~kraih/Mojolicious-0.999926/lib/Mojo/Cookie/Request.pm
Netscape Cookie に加え、
RFC 2109 か RFC 2965 の Cookie: の構文解析に対応しています。
[59] CGIメタ変数 HTTP_COOKIE は HTTP
の Cookie: 欄に対応します。詳しくは HTTP_* を参照してください。
[60] WebSite は HTTP_COOKIE のかわりにメタ変数
COOKIE を使っているそうです。
[6] Cookie を設定する Set-Cookie: 頭欄と同じように名前と値の組を並べる形式ではありますが、
Set-Cookie: は1つの名前と値の組を設定するのに対し、
Cookie: は複数の名前と値の組を1つにまとめて記述できます。
[96] draft-pettersen-cookie-origin-02 - Identifying origin server of HTTP Cookies ( ( 版)) http://tools.ietf.org/html/draft-pettersen-cookie-origin-02
[97] draft-willis-sip-cookies-00 - SIP Cookies ( ( 版)) https://tools.ietf.org/html/draft-willis-sip-cookies-00#section-4
[106] Clarify the hooks into RFC6265 · whatwg/fetch@5a324a8 ( 版) https://github.com/whatwg/fetch/commit/5a324a891c42d42de09a01e03c3a063b9a4f882b
多くのcookie parserは、pairsの区切りとして ; と , を許容しているのでdjango以外にも影響がある。 ブラウザが使用するcookie pairの区切りは実際には ;
CGI::Cookieでは "[;,] ?"
[108] , を区切りとする元凶は RFC 2965 とのこと...
# Sets the parsing mode for parsing cookies.
# The following value are defined:
#
# `rfc6265`: Only RFC6265-compliant cookies are parsed. Surrounding double-quotes are accepted and
# automatically removed. Non-compliant cookies are silently discarded.
# `raw`: Raw parsing allows any non-control character but ';' to appear in a cookie value. There's no further
# post-processing applied, so that the resulting value string may contain any number of whitespace, unicode,
# double quotes, or '=' characters at any position.
# The rules for parsing the cookie name are the same ones from RFC 6265.
#
cookie-parsing-mode = rfc6265