[1] Cookie: ヘッダー は、
利用者エージェント に保存されているクッキー を示します。
[95] クッキー 一般に関しては、クッキー の項を参照。仕様書 [61] RFC 6265 - HTTP State Management Mechanism (2012-03-01 09:57:02 +09:00 版) http://tools.ietf.org/html/rfc6265#section-3 [64] RFC 6265 - HTTP State Management Mechanism (2012-03-01 09:57:02 +09:00 版) http://tools.ietf.org/html/rfc6265#section-4.2 [23] RFC 6265 - HTTP State Management Mechanism (2014-10-12 15:11:47 +09:00 版) http://tools.ietf.org/html/rfc6265#section-5.4 [93] RFC 6265 - HTTP State Management Mechanism (2014-10-12 15:11:47 +09:00 版) http://tools.ietf.org/html/rfc6265#section-7.2 [100] RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2) (2015-05-15 10:14:54 +09:00 版) https://tools.ietf.org/html/rfc7540#section-8.1.2.5 構文 [65] Cookie: ヘッダー の値は、 cookie-string です。
RFC 6265
[101] cookie-string 以上 の cookie-pair の列です。cookie-pair 間には
; SP RFC 6265
cookie-string *; SP cookie-string [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 空白 ではなく、 ; = 空白 ではなく、
;
文脈 [75] 利用者エージェント は、蓄積されているクッキー があれば
Cookie: ヘッダー を要求 に含めます >>24
[5] 利用者エージェント は、 HTTP/1.1 以下 の要求 で複数の
Cookie: ヘッダー を生成 してはなりません >>24
[71] HTTP では一般に複数の同じ名前のヘッダー を , クッキー の名前や値に , RFC 6265 の構文は , 鯖 が発行したクッキー なら曖昧性はありませんが、
そうでないものを鯖 側で処理する可能性を想定するのであれば、 , [103] HTTP/2 では、1つ以上 の cookie-pair が値となる
Cookie: ヘッダー 複数個に分割して含めても構いません >>100
[104] これは、個々の cookie-pair が更新されることを想定したヘッダー圧縮 の効率の向上のための策です
>>100 [76] しかし利用者エージェント は Cookie: ヘッダー を省略しても構いません >>24
[77] 例えば「第三者 」要求 でクッキー を送信しなくても構いません >>24
[94] 利用者エージェント は、クッキー が無効に設定されている時、
Cookie: ヘッダー を要求 に含めてはなりません >>93
[99] WebSocket handshake でも使うことができます。
[110]
cookie-string は、
curl
の
--cookie
でも使われます。
ヘッダーの生成 [78] 利用者エージェント は、次の条件をすべて満たすクッキー を使って
Cookie: ヘッダー を生成 しなければなりません >>24 [79] 次のいずれかを満たす[80] クッキー のホストのみフラグが設定されていて、正準化要求ホスト がクッキー のドメイン と同じである[81] クッキー のホストのみフラグが設定されておらず、正準化要求ホスト がクッキー のドメイン とドメイン一致 する[82] 要求URL のパス がクッキー のパス とパス一致 する[83] クッキー の保安のみフラグが設定されている場合、
要求URL の URL scheme が「保安」プロトコル を示している
[11] リダイレクト によって再度 HTTP 要求 を送信する場合であっても、
(新しい URL に関して) 通常通り適用される Cookie を調べて
Cookie: 頭欄 を構築するべきです。[74] 利用者エージェント は、 Cookie: ヘッダー を生成 する際にクッキー を次のように整列 するべき >>24 [84] クッキー のパス が長いものを短いものより先に[85] クッキー のパス の長さが同じものは、生成時刻が古いものを新しいものより前に
[86] この順序は RFC 6265 の出版時点で一般的な習慣となっているものの、
すべての利用者エージェント がそうしているわけではないとされています >>24 必須 推奨 鯖 も歴史的には存在していることが知られています
>>24 必須 [98] >>84 の条件より、より深いディレクトリー 向けのクッキー が先に来ますから、
鯖 としてはより前にあるクッキー を使うのがより良い方針のように思われます。
一方 >>85 の方針より、既存のクッキー を上書きするべきクッキー がなぜか上書きされなかった場合により後のクッキー を取るのがより良い方針とも思えます。
名前とパスが同じ重複したクッキー が保存される場合というのはドメイン が異なるクッキー が存在する場合です (Set-Cookie: [87] 利用者エージェント は、>>78 で得られたクッキー を >>74
で整列 し、 ; SPACE Cookie: ヘッダー として使わなければなりません クッキー は名前と値を = なりません >>24
[90] 蓄積されていたクッキー に RFC 6265 の構文に適合しない名前や値が含まれていた場合には、
ここでそのまま出力することになりますから、 RFC 6265 の
Cookie: ヘッダー の構文に適合しない結果になることもあります。[91] クッキー の名前や値はバイト列 で、ここで連結して得られる結果もバイト列 です。[89] 該当するクッキー が一つもない場合には、 Cookie: ヘッダー 自体を生成 しません。[88] また利用者エージェント は >>78 で得られたクッキー の最終アクセス時刻を現在日時に設定しなければなりません >>24
処理 [63] 起源鯖 は Cookie: >>61
[68] クッキー は順番に並べることになってはいますが、鯖 ではそれに依存するべきではありません クッキー が複数ある場合に、これがどの順番で現れるかに依存するべきではありません >>64
[73] RFC 6265 は (利用者エージェント による Set-Cookie: ヘッダー の構文解析を詳細に規定しているのに対して) 起源鯖 による
Cookie: ヘッダー の構文解析の方法を詳細には規定していません。
鯖 が適合する Set-Cookie: ヘッダー を出力し、
利用者エージェント が適合する方法で処理する限り、
Cookie: ヘッダー の値は常に ABNF
構文に適合するはずなので、それ以上に構文解析法を規定する必要もないのかもしれません。
あるいは鯖 が内部でどのようにヘッダー の値を解釈するかは鯖 側の著者 (開発者)
以外には観測できず、適合性を議論するのが難しいという事情もあるかもしれません。[92] 起源鯖 は、クライアント が仕様に適合しない Cookie: ヘッダー を送信してきた場合にも (エラーを返すなど) 適当な処理を行えなければなりません。
Webブラウザー 以外から適合しない Cookie: ヘッダー が送られたり、 Webブラウザー からも (著者 のミスや悪意ある利用者 により)
適合しない Cookie: ヘッダー が送られたりする可能性は排除できません。
またライブラリー の類は、Webアプリケーション の開発者が不適合な
Set-Cookie: ヘッダー を送信している可能性を排除できませんから、
不適合な Cookie: ヘッダー であってもできるだけ“正しく”
処理できることが求められます。[102] HTTP/1.1 以下 で Cookie: ヘッダー が複数ある場合にどう処理するべきかは不明です。
[72] RFC 6165 は鯖 がこの辺りをどう処理するべきか特に規定していません。
通常は鯖 が名前や値を制御できるので、そのようなものを出力しなければ良いだけです。
ただ実際には他の鯖 から第三者的に発行することもできてしまいますし、
鯖 側の実装と JavaScript の実装を別の著者が行なってい (て HTTP
の制限を見落としてい) る場合など、まったく無視できる問題でもありません。
>>73 の制限があるので、これに従う (一般的な) 利用者エージェント を想定するなら、
, ヘッダー の連結ではなく、名前や値の一部と常に仮定していいかもしれません。[105] HTTP/2 で複数の Cookie: ヘッダー がある場合、
HTTP/1.1 接続 や汎用 HTTP サーバー応用など HTTP/2
以外へと引き渡される時は、 ; SP なりません >>100
[62] Cookie: キャッシュ可能性 に影響しません >>61
[10] 串 は Cookie: 鯖 へと転送するべきです。
それがたとえ If-Modified-Since: 条件付き要求 であってもです。
>>2
歴史 Netscape Cookie [2] Netscape Cookie : Client Side State - HTTP Cookies
http://web.archive.org/web/19961125090609/http://www2.netscape.com/newsref/std/cookie_spec.html [3]
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 ...
>>2 [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 (2011-12-30 23:35:34 +09:00 版) http://cpansearch.perl.org/src/MARKSTOS/CGI.pm-3.59/lib/CGI/Cookie.pm
は、古い Netscape が複数の同じ名前のクッキー を送ることがあり、一番前のものが最新であるとしてそれを使っています。
RFC の Cookie: 頭欄の定義 [19] RFC 2109 , RFC 2965 では Netscape Cookie とはあまり互換性がない
Cookie: 頭欄 が定義されていました >>17 , >>18
概要:
[20] 名前と値の組が1つ以上含まれるのは Netscape Cookie と同じでした。[35] 名前は token token quoted-string >>17 , >>18 [21] 名前と値の組の前に Cookie の版 を $Version =1>>17 , >>18 [22] $VersionCookie に対応する
Set-Cookie Set-Cookie2 Version 0 >>17 , >>18 [24] 混在する場合どうするのでしょうか。[33] Set-Cookie Set-Cookie2 Version [34] Set-Cookie2 Version [25] 名前と値の組の後に ; $Path =... のように属性 を指定することになっていました
>>17 , >>18 [26] $Path >>17 , >>18 $Domain >>17 , >>18 $Port >>18 [27] Set-Cookie Set-Cookie2 Path Domain Port 属性 があった場合は同じ値 (または同じように値なし) でなければなりません >>17 , >>18 属性 自体がなかった場合には $Path $Domain べき >>17 , >>18 $Port ならない >>18 [28] つまり、属性 がなくて既定値が補われた場合と明示的に値が指定されていた場合は区別して蓄積しておく必要があるということですね。[29] 名前と値の組の順序は、Path >>17 , >>18 [30] Netscape Cookie と同じですね。[31] それ以外の Domain 規定しないunspecified
>>17 , >>18 [32] 名前と値の組同士の区切りは後方互換性 のため ; 鯖 は , ならない ABNF 構文上もそうなっていました。 >>17 , >>18 [38] 鯖 は、 $ べきです >>36 , >>37 [39] なぜか MUST ではなくて SHOULD でした。[40] $ 属性 は、前から順に調べていって、一番最初の $ 属性 の手前までは全体に適用される属性 、その後は直前の $ 属性 に適用される属性 と解釈するとされていました >>36 [41] この規定は RFC 2109 にはありましたが、なぜか RFC 2965 にはありませんでした。[44] 串 は自身で勝手に Cookie: 応答 に付け足してはなりません >>42 , >>43 [46] Netscape Cookie の互換性について、次のようなことが言われていました >>45
[47] 旧クライアントは新しい Cookie を受け取ると知らないものは無視し、理解できるものを使って
Cookie: [48] 新クライアントは Cookie を常に新形式で送る[49] 旧鯖は「$ ]」で始まる属性 をそういう Cookie だと思って無視する[50] ただし「, ; [51] 新鯖は「$Version [52] >>46 を読むと一見後方互換性 が保たれていると錯覚してしまいがちですが、
新 Cookie では属性 の値が引用文字列 でもあり得るので、
旧クライアント・旧鯖は引用符も値の一部だと思ってしまうという問題があります。
[54] 起源鯖 はクライアントが新 Cookie を理解すると分かっていないときは、引用符が必要な値に注意するべきです。 >>53 [55] 新しいクライアントは Cookie の版がすべて RFC 2109 以降であるときだけ値を引用符で括るべきです。 >>53 [56] >>48 より新クライアントは常に新 Cookie を送ることになっているので、
常に引用文字列 で送る新クライアントは旧鯖とは正しくやり取りできなくなり、 >>55
のような注意が必要になるわけです。でも >>54 のように注意しろと言われても困った話です。
引用符が必要な値だけど引用符を使えないときは引用符を外していいのでしょうか。
でも外すと RFC 2109 には適合しなくなります。
[57] また、 RFC 2109 は「= 空白 についても、
Netscape Cookie では認められていなかったので注意するよう書いています >>53
[16] RFC 2109 と RFC 2965 は、利用者エージェント は各種規則に基づき
Cookie: 応答 頭欄を送信するべきである >>14 , >>15 [12] RFC 2109 廃止 済み)[14] 4.2.1 General [17] 4.3.4 Sending Cookies to the Origin Server [36] 4.4 How an Origin Server Interprets the Cookie Header [42] 4.5 Caching Proxy Role [45] 10.1.1 Extended Cookie Header [53] 10.1.3 Punctuation [13] RFC 2965 [15] 3.2.1 General [18] 3.3.4 Sending Cookies to the Origin Server [37] 3.4 How an Origin Server Interprets the Cookie Header [43] 3.5 Caching Proxy Role 実装 [58] Mojo::Cookie::Request - search.cpan.org (2010-08-01 16:26:16 +09:00 版) http://search.cpan.org/~kraih/Mojolicious-0.999926/lib/Mojo/Cookie/Request.pm
Netscape Cookie に加え、
RFC 2109 か RFC 2965 の Cookie:
CGI メタ変数 [59] CGIメタ変数 HTTP_COOKIE HTTP
の Cookie: HTTP_*
[60] WebSite は HTTP_COOKIE メタ変数
COOKIE
関連 [6] Cookie を設定する Set-Cookie: 頭欄 と同じように名前 と値の組を並べる形式ではありますが、
Set-Cookie: Cookie:
[96] draft-pettersen-cookie-origin-02 - Identifying origin server of HTTP Cookies
( (2014-10-16 15:24:02 +09:00 版))
http://tools.ietf.org/html/draft-pettersen-cookie-origin-02
[97] draft-willis-sip-cookies-00 - SIP Cookies
( (2014-10-18 18:10:29 +09:00 版))
https://tools.ietf.org/html/draft-willis-sip-cookies-00#section-4
[106] Clarify the hooks into RFC6265 · whatwg/fetch@5a324a8
(2016-03-01 11:27:58 +09:00 版)
https://github.com/whatwg/fetch/commit/5a324a891c42d42de09a01e03c3a063b9a4f882b
[107] CVE-2016-7401 CSRF protection bypass on a site with Google Analytics の解説 · GitHub
( (2017-04-23 17:08:39 +09:00 ))
https://gist.github.com/mala/457a25650950d4daf4144f98159802cc 多くのcookie parserは、pairsの区切りとして ; と , を許容しているのでdjango以外にも影響がある。 ブラウザが使用するcookie pairの区切りは実際には ;
CGI::Cookieでは "[ ;,] ?"
[108] , を区切りとする元凶は RFC 2965 とのこと...
[109] Configuration • Akka HTTP
(2018-03-27 23:00:57 +09:00 )
https://doc.akka.io/docs/akka-http/current/configuration.html # 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