Internet Engineering Task Force (IETF)
RFC 6265
廃用 RFC 2965
分類 Standards Track
ISSN 2070-1721
編集 A. Barth, U.C. Berkeley
発行 2011 年 4 月

HTTP 状態管理メカニズム

要約

この文書は HTTP CookieSet-Cookie ヘッダを規定する。 これらのヘッダは、(クッキーと呼ばれる)状態­情報を HTTP 利用者エージェント側に格納させるために, HTTP サーバにより利用され得るものであり、状態­情報をほとんど持たない HTTP プロトコル上で,サーバが状態を保つセッションを維持管理できるようにする。 クッキーには、セキュリティとプライバシーの品質を落とす,多くの歴史的な欠陥が存在してはいるが、 CookieSet-Cookie ヘッダはインターネット上で広範に利用されている。 この文書は RFC 2965 を廃用にする。 This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965.

このメモの位置付け

これは、インターネット標準化過程( Internet Standards Track )文書である。 This is an Internet Standards Track document.

この文書は、 IETF よる成果物であり, IETF コミュニティの合意を表現するものである。 それは、公開の評価を受け, IESG から発行が承認されたものである。 Internet 標準についての更なる情報は RFC 5741, 2 節 に見られる。 This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

この文書の現在の位置付け, 正誤表, フィードバックの仕方についての情報は、 http://www.rfc-editor.org/info/rfc6265 を参照されたし。 Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6265.

著作権の告知

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

この文書は、その発行の日付から有効なものとして、 BCP 78, および IETF Trust の IETF Documents に対する Legal Provisions Relating の対象になる( http://trustee.ietf.org/license-info )。 これらの文書には、この文書に関するあなたの権利と制約条項が述べらているので,入念に査読されたし。 この文書から取り出された Code Components は、 Trust Legal Provisions の 4.e 節 に述べられるように, Simplified BSD License テキストを含んでいなければならず、 Simplified BSD License に述べられるように,無保証で提供される。 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書には、 2008 年 11 月 10 日より前に発行または公開された, IETF 文書や IETF Contributions からの素材が含まれているかもしれない。 その素材の一部分について、その著作権を管理する者(たち)は IETF Standards Process の外部において、改変を許諾する権利を IETF Trust に認可していないかもしれない。 IETF Standards Process の外部において、この文書を改変したり,あるいは( RFC として公開するために書式を整える,または英語以外の言語に翻訳する場合を除き)派生物を作成するためには、その著作権を管理する者(たち)から,法的な意味で許諾を得る必要がある。 This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

1. 序論

この文書は、 HTTP の CookieSet-Cookie ヘッダを規定する。 Set-Cookie ヘッダの利用により、 HTTP サーバは,クッキーと呼ばれる[[名前, 値]の組と関連のメタデータ]を UA に渡すことができる。 UA は,サーバへ後続のリクエストを行う際に,その[名前, 値]の組を Cookie ヘッダの中に返すかどうか決めるにあたり、そのメタデータと他の情報を利用する。 This document defines the HTTP Cookie and Set-Cookie header fields. Using the Set-Cookie header field, an HTTP server can pass name/value pairs and associated metadata (called cookies) to a user agent. When the user agent makes subsequent requests to the server, the user agent uses the metadata and other information to determine whether to return the name/value pairs in the Cookie header.

【 “ヘッダ” : 正式には “ヘッダフィールド( header field )” だが、当訳では一律に “ヘッダ” と略記する。 】【 “UA”: 利用者エージェント( user agent ) — 当訳ではこの略記に統一する。 】

見かけの単純さに反し、クッキーはいくつかの複雑さを孕んでいる。 例えば,サーバは、 UA に向けて送信するそれぞれのクッキーについて,スコープ 【対象範囲】 を指示する。 スコープは,[ UA がクッキーを返すべき期間, UA がクッキーを返すべきサーバ, クッキーを適用し得る URI スキーム ]を指示する。 Although simple on their surface, cookies have a number of complexities. For example, the server indicates a scope for each cookie when sending it to the user agent. The scope indicates the maximum amount of time in which the user agent should return the cookie, the servers to which the user agent should return the cookie, and the URI schemes for which the cookie is applicable.

歴史的な理由から、クッキーは,セキュリティとプライバシーに関わる いくつかの欠陥を孕んでいる。 例えば、サーバは, Secure 属性により クッキーの用途が “セキュア” 接続であることを指示できるが、それは,ネットワーク攻撃者の存在下において完全性を提供するものではない。 同様に、一つのホストに対するクッキーは、ウェブブラウザに利用される通常の “同一生成元ポリシー” ( same-origin policy )により,異なるポートから取得される内容が隔離されるにも関わらず、そのホスト上のすべてのポートにわたって共有される。 For historical reasons, cookies contain a number of security and privacy infelicities. For example, a server can indicate that a given cookie is intended for "secure" connections, but the Secure attribute does not provide integrity in the presence of an active network attacker. Similarly, cookies for a given host are shared across all the ports on that host, even though the usual "same-origin policy" used by web browsers isolates content retrieved via different ports.

この仕様が想定する読者は、クッキーを生成するサーバの開発者とクッキーを消費する UA の開発者である。 There are two audiences for this specification: developers of cookie-generating servers and developers of cookie-consuming user agents.

UA との相互運用性を最大にするため、サーバは, 4 節 に定義される well-behaved profile に従って,クッキーを生成するべきである。 To maximize interoperability with user agents, servers SHOULD limit themselves to the well-behaved profile defined in Section 4 when generating cookies.

UA は、 4 節 にて規定される well-behaved profile に適合しない既存サーバとの相互運用性を最大にするため、 5 節 にて規定される,より寛容な処理規則を実装しなければならない User agents MUST implement the more liberal processing rules defined in Section 5, in order to maximize interoperability with existing servers that do not conform to the well-behaved profile defined in Section 4.

この文書は、これらのヘッダの構文と意味論を,インターネットにおける実際の利用に沿う形で指定する。 特に、この文書は,今日の利用を超えた新たな構文や意味論を創出するものではない。 4 節 にて与える,クッキー生成についての推奨は、現今のサーバのふるまいの好ましいサブセットを表現する。 5 節 にて与える,より寛容なクッキー処理アルゴリズムは、今日利用されている構文や意味論のバリエーションについて,そのすべてを推奨するものではない。 この文書では、一部の既存ソフトウェアにおける,推奨プロトコルとの重要な差異についても説明される。 This document specifies the syntax and semantics of these headers as they are actually used on the Internet. In particular, this document does not create new syntax or semantics beyond those in use today. The recommendations for cookie generation provided in Section 4 represent a preferred subset of current server behavior, and even the more liberal cookie processing algorithm provided in Section 5 does not recommend all of the syntactic and semantic variations in use today. Where some existing software differs from the recommended protocol in significant ways, the document contains a note explaining the difference.

この文書­以前に、少なくとも3つの,クッキーについて述べた文書がある: いわゆる "Netscape クッキー仕様" [Netscape], [RFC2109], [RFC2965] 。 しかしながら、これらのどの文書も Cookie ヘッダと Set-Cookie ヘッダがインターネット上で実際にどのように利用されているかについて述べていない(歴史的背景については [Kri2001] を参照)。 HTTP 状態­管理の仕組みについて述べている,以前の IETF 仕様に関連して、この文書は以下のアクションを要請する: Prior to this document, there were at least three descriptions of cookies: the so-called "Netscape cookie specification" [Netscape], RFC 2109 [RFC2109], and RFC 2965 [RFC2965]. However, none of these documents describe how the Cookie and Set-Cookie headers are actually used on the Internet (see [Kri2001] for historical context). In relation to previous IETF specifications of HTTP state management mechanisms, this document requests the following actions:

  1. [RFC2109] の位置付けを Historic (歴史的)に変更(これは [RFC2965] により,すでに廃用( obsolete )にされている)。 Change the status of [RFC2109] to Historic (it has already been obsoleted by [RFC2965]).

  2. [RFC2965] の位置付けを Historic に変更。 Change the status of [RFC2965] to Historic.

  3. [RFC2965] は、この文書により廃用にされる。 Indicate that [RFC2965] has been obsoleted by this document.

特に、 [RFC 2965] の Historic への移行と廃用に伴い、この文書は Cookie2 および Set-Cookie2 ヘッダの利用を廃止する。 In particular, in moving RFC 2965 to Historic and obsoleting it, this document deprecates the use of the Cookie2 and Set-Cookie2 header fields.

2. 表記規約

2.1. 適合性基準

この文書におけるキーワード: 「〜しなければ(〜しては)ならない」 = “MUST (NOT)”, 「要求される」= REQUIRED, 「〜すべきである(でない)」 = “SHOULD (NOT)”, 「推奨される」 = “RECOMMENDED”, 「〜してもよい」 = “MAY”, 「任意選択 」 = “OPTIONAL”, は、 [RFC2119] に則って解釈されるものとする。 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

アルゴリズムの中の命令的言い回しによる要件(例えば「頭部のスペース文字並びを取り除く」, 「 false を返してこの手続きを中止する」など)は、アルゴリズムを引用する際に利用されているキーワード(「〜しなければならない」, 「〜すべき」, 「〜してもよい」, 等々)の意味の下に解釈されることになる。 Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("MUST", "SHOULD", "MAY", etc.) used in introducing the algorithm.

アルゴリズムまたは特定の手続きとして記される適合性の要件は、最終的な結果が等価になるのであれば,どのように実装されてもよい。 特に、この仕様で定義されるアルゴリズムは理解し易くなるように記述されており,パフォーマンスは考慮されていない。 Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant.

2.2. 構文の記法

この仕様は [RFC5234] による ABNF ( Augmented Backus-Naur Form )記法を用いる。 This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234].

次の基本規則が RFC 5234, Appendix B.1 和訳 にて規定されるものとして,参照される:

  • ALPHA (アルファベット )
  • CR ( carriage return )
  • CRLF ( CR LF )
  • CTL (制御文字)
  • DIGIT ( 10 進数字 0-9 )
  • DQUOTE (二重引用符)
  • HEXDIG ( 16 進数字 0-9/A-F/a-f )
  • LF ( line feed )
  • NUL ( null オクテット )
  • OCTETNUL 以外の任意の 8-bit 並びのデータ)
  • SP (スペース)
  • HTAB (水平タブ)
  • CHAR【 NUL を除く】任意の [USASCII] 文字)
  • VCHAR (任意の可視 [USASCII] 文字)
  • WSP (空白類【 SP と HTAB 】)。

The following core rules are included by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTLs (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), NUL (null octet), OCTET (any 8-bit sequence of data except NUL), SP (space), HTAB (horizontal tab), CHAR (any [USASCII] character), VCHAR (any visible [USASCII] character), and WSP (whitespace).

OWS (オプションの空白類)規則は、ゼロ個以上の連続する空白類が現れてもよい場所に利用される: The OWS (optional whitespace) rule is used where zero or more linear whitespace characters MAY appear:

OWS            = *( [ obs-fold ] WSP )
                 ; "オプションの" 空白類
obs-fold       = CRLF

OWS は、空(生成されない)または1個の SP 文字として生成されるべきである。 OWS SHOULD either not be produced or be produced as a single SP character.

2.3. 用語

語[ UA (利用者エージェント), クライアント, サーバ, プロキシ, 生成元( origin )サーバ ]の意味は、 HTTP /1.1 仕様( RFC 2616, 1.3 節 [RFC2616])に従う。 The terms user agent, client, server, proxy, and origin server have the same meaning as in the HTTP/1.1 specification ([RFC2616], Section 1.3).

request-host とは、UA に既知のホスト名 — UA が HTTP リクエストを送信している相手, あるいは UA が HTTP 応答を受信した相手(すなわち, UA が対応する HTTP リクエストを送信した相手)のホスト名 — を意味する。 The request-host is the name of the host, as known by the user agent, to which the user agent is sending an HTTP request or from which it is receiving an HTTP response (i.e., the name of the host to which it sent the corresponding HTTP request).

request-uri は、 RFC 2616, 5.1.2 節 にて規定される。 The term request-uri is defined in Section 5.1.2 of [RFC2616].

2つの[オクテット並び]は、 [RFC4790] にて規定される i;ascii-casemap 照合 の下に等価であるとき, そのときに限り, 文字大小無視で合致する とされる。 【 ASCII 範囲のオクテットの, a-z, A-Z の範囲の文字のみ、文字の大小を区別せずに,対応する文字を同一視する。 】 Two sequences of octets are said to case-insensitively match each other if and only if they are equivalent under the i;ascii-casemap collation defined in [RFC4790].

文字列 とは、非 NUL のオクテットからなる並びを意味する。 【 したがって、語「文字」も,特に断らない限り,(非 NUL の)1個のオクテットを意味する。 また、空­文字列(長さゼロの文字列)の略記として,語「空」が用いられる。 】 The term string means a sequence of non-NUL octets.

3. 概観

この節では、生成元サーバが状態­情報を UA に向けて送信する方法, および UA がその状態­情報を生成元サーバに返す方法,についての概略を述べる。 This section outlines a way for an origin server to send state information to a user agent and for the user agent to return the state information to the origin server.

生成元サーバは、UA に状態を格納させるために, HTTP 応答に Set-Cookie ヘッダを内包させる。 UA による後続のリクエストにおいては、 UA は,以前に Set-Cookie ヘッダで受信したクッキーを含ませた Cookie リクエスト­ヘッダを,生成元サーバに返す。 生成元サーバが、その Cookie ヘッダを無視するのも, その内容をアプリケーション定義の目的に利用するのも,任意である。 To store state, the origin server includes a Set-Cookie header in an HTTP response. In subsequent requests, the user agent returns a Cookie request header to the origin server. The Cookie header contains cookies the user agent received in previous Set-Cookie headers. The origin server is free to ignore the Cookie header or use its contents for an application-defined purpose.

生成元サーバは、任意の応答に Set-Cookie 応答ヘッダを送信してよい。 UA は 100 番台のステータスコードを伴う応答に対しては,その中の Set-Cookie ヘッダを無視してもよいが、他の応答( 400 番台, および 500 番台のステータスコードを伴う応答も含む)の中の Set-Cookie ヘッダについては,処理しなければならない。 生成元サーバは、単独の応答に複数の Set-Cookie ヘッダを内包させられる。 CookieSet-Cookie ヘッダの存在は、 HTTP キャッシュによる,応答の格納や再利用を妨げるものではない。 Origin servers MAY send a Set-Cookie response header with any response. User agents MAY ignore Set-Cookie headers contained in responses with 100-level status codes but MUST process Set-Cookie headers contained in other responses (including responses with 400- and 500-level status codes). An origin server can include multiple Set-Cookie header fields in a single response. The presence of a Cookie or a Set-Cookie header field does not preclude HTTP caches from storing and reusing a response.

生成元サーバは、単独のヘッダ内に,複数の Set-Cookie ヘッダを織り込むべきでない。 HTTP ヘッダに織り込む通常の仕組み( [RFC2616] にて規定される)の利用は、 Set-Cookie における %x2C ( "," )の利用と競合するので, Set-Cookie ヘッダの意味論を変更し得る。 Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field. The usual mechanism for folding HTTP headers fields (i.e., as defined in [RFC2616]) might change the semantics of the Set-Cookie header field because the %x2C (",") character is used by Set-Cookie in a way that conflicts with such folding.

3.1. 例

サーバは、UA への HTTP 応答に Set-Cookie ヘッダを利用して — UA が,そのクッキーのスコープに入る未来の HTTP リクエストにおいて返すことになる — 短い文字列を送信できる。 例えば,サーバは、[ 名前 SID, 値 31d4d96e407aad42 ]の “セッション識別子” を, UA に向けて送信できる。 UA は、後続のリクエストにて,そのセッション識別子を返すことになる: Using the Set-Cookie header, a server can send the user agent a short string in an HTTP response that the user agent will return in future HTTP requests that are within the scope of the cookie. For example, the server can send the user agent a "session identifier" named SID with the value 31d4d96e407aad42. The user agent then returns the session identifier in subsequent requests.

== サーバ → UA ==

Set-Cookie: SID=31d4d96e407aad42

== UA → サーバ ==

Cookie: SID=31d4d96e407aad42

サーバは、 Path および Domain 属性を用いて,クッキーの既定のスコープを改められる。 例えば,サーバは、 UA に対し, example.com のどのパスに対しても, あるいはどの下位ドメインに対しても,そのクッキーを返すように、指図できる: The server can alter the default scope of the cookie using the Path and Domain attributes. For example, the server can instruct the user agent to return the cookie to every path and every subdomain of example.com.

== サーバ → UA ==

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

== UA → サーバ ==

Cookie: SID=31d4d96e407aad42

次の例に示されるように、サーバは,複数のクッキーを UA 側に格納できる。 例えば,サーバは、2つの Set-Cookie ヘッダを返すことにより、セッション識別子と同時に,利用者が希望する言語も格納できる。 サーバは、よりセキュリティに敏感なセッション識別子に対しては,追加の保護を提供する Secure および HttpOnly 属性を利用することに注意( 4.1.2 節 を見よ): As shown in the next example, the server can store multiple cookies at the user agent. For example, the server can store a session identifier as well as the user's preferred language by returning two Set-Cookie header fields. Notice that the server uses the Secure and HttpOnly attributes to provide additional security protections for the more sensitive session identifier (see Section 4.1.2.)

== サーバ → UA ==

Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly
Set-Cookie: lang=en-US; Path=/; Domain=example.com

== UA → サーバ ==

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

上の Cookie ヘッダには、名前 SID の, および名前 lang の,2つのクッキーが含まれていることに注意。 UA において “複数セッション” に渡る(例えば UA の再起動を挟んだ)クッキーの存続が望まれる場合、サーバは, Expires 属性にその有効期限を指定できる。 UA は、自身のクッキー保管庫の総容量が割り当て分を超過した場合や,利用者が手動でサーバのクッキーを削除した場合など、有効期限が過ぎる前にクッキーを削除し得ることに注意。 Notice that the Cookie header above contains two cookies, one named SID and one named lang. If the server wishes the user agent to persist the cookie over multiple "sessions" (e.g., user agent restarts), the server can specify an expiration date in the Expires attribute. Note that the user agent might delete the cookie before the expiration date if the user agent's cookie store exceeds its quota or if the user manually deletes the server's cookie.

== サーバ → UA ==

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

== UA → サーバ ==

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

最後に、クッキーを除去するためには、サーバは,有効期限を過去にした Set-Cookie ヘッダを返す。 サーバによるクッキーの除去が成功するのは、 Set-Cookie ヘッダの中の PathDomain 属性が,クッキーの作成時に利用された値に合致するときに限られる。 Finally, to remove a cookie, the server returns a Set-Cookie header with an expiration date in the past. The server will be successful in removing the cookie only if the Path and the Domain attribute in the Set-Cookie header match the values used when the cookie was created.

== サーバ → UA ==

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

== UA → サーバ ==

Cookie: SID=31d4d96e407aad42

4. サーバに課される要件

この節では CookieSet-Cookie ヘッダの構文と意味論の well-behaved profile 【整合性を保つふるまいのための仕様】 について述べる。 This section describes the syntax and semantics of a well-behaved profile of the Cookie and Set-Cookie headers.

4.1. Set-Cookie ヘッダ

Set-Cookie HTTP 応答ヘッダは、 サーバから UA へのクッキーの送信に利用される。 The Set-Cookie HTTP response header is used to send cookies from the server to the user agent.

4.1.1. 構文

概略的には, Set-Cookie 応答ヘッダは[ ヘッダ名 "Set-Cookie", 文字 ":", 1個のクッキー ]の並びからなる。 各クッキーは、1個の name-value-pair ([ 名前 cookie-name, 値 cookie-value ]の組)から開始され,ゼロ個以上の属性([ 名前 attribute-name, 値 attribute-value ]の組)が後続する。 サーバは、次の文法に適合しない Set-Cookie ヘッダを送信するべきでない。 Informally, the Set-Cookie response header contains the header name "Set-Cookie" followed by a ":" and a cookie. Each cookie begins with a name-value-pair, followed by zero or more attribute-value pairs. Servers SHOULD NOT send Set-Cookie headers that fail to conform to the following grammar:

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
                      ; CTL, 空白類, DQUOTE, カンマ, セミコロン,
                      ; バックスラッシュ, を除く US-ASCII 文字
token             = <tokenRFC 2616, 2.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-dateRFC 2616, 3.3.1 節にて規定される>
max-age-av        = "Max-Age=" non-zero-digit *DIGIT
                      ; 実施上は, expires-avmax-age-av のいずれも
                      ; UA が表現し得る日付の範囲に制限される。
non-zero-digit    = %x31-39
                      ; 数字 1 〜 9
domain-av         = "Domain=" domain-value
domain-value      = <subdomain>
                      ; RFC 1034, 3.5 節にて規定され,
                      ; RFC 1123, 2.1 節にて拡張される
path-av           = "Path=" path-value
path-value        = *<CTL と ";" 以外の任意の CHAR>
secure-av         = "Secure"
httponly-av       = "HttpOnly"
extension-av      = *<CTL と ";" 以外の任意の CHAR>

path-valueextension-av の先頭の "*" は、正誤表による修正( Verified )による。 】

上の中の一部の文法記号は、この文書の文法­記法( ABNF [RFC5234] )とは異なる記法を利用する文書を参照していることに注意。 Note that some of the grammatical terms above reference documents that use different grammatical notations than this document (which uses ABNF from [RFC5234]).

cookie-value の意味論は、この文書では定義されない。 The semantics of the cookie-value are not defined by this document.

UA との互換性を最大にするためには、 cookie-value の中に任意のデータを格納することを望むサーバは、そのデータを符号化するべきである(例えば, Base64 [RFC4648] を用いて)。 To maximize compatibility with user agents, servers that wish to store arbitrary data in a cookie-value SHOULD encode that data, for example, using Base64 [RFC4648].

set-cookie-string の中で,文法記号 cookie-av が生成する部分は、 属性 と呼ばれる。 UA との互換性を最大にするためには、サーバは,1つの set-cookie-string の中に同じ名前の2つの属性を生成するべきでない。 ( UA がこの場合をどのように扱うかについては、 5.3 節 を見よ) The portions of the set-cookie-string produced by the cookie-av term are known as attributes. To maximize compatibility with user agents, servers SHOULD NOT produce two attributes with the same name in the same set-cookie-string. (See Section 5.3 for how user agents handle this case.)

サーバは、同じ応答­内に同じ cookie-name の複数の Set-Cookie ヘッダを内包するべきでない。 ( UA がこの場合をどのように扱うかについては、 5.2 節 を見よ。†) Servers SHOULD NOT include more than one Set-Cookie header field in the same response with the same cookie-name. (See Section 5.2 for how user agents handle this case.)

【† と記されているが、この場合の取り扱いは,明快な形では述べられていない。 UA が該当するクッキーを 受信した (あるいは,ヘッダが現れる)順番通りに処理し, かつ そのそれぞれを無視しないと見なすならば、あたかも,そのそれぞれが別々の応答で受信されたかのように処理することになると考えられる。 (例えば name が同じでも, path が異なれば、保管の際には別々に扱われる。) しかしながら、 5.2 節には “UA は Set-Cookie ヘッダを無視してもよい” とも記されているので、この種の重複に際し,最初のものだけが有効にされる実装も考えられなくはない。 】

サーバが Set-Cookie ヘッダを含んでいる複数の応答を,同時に UA に送信した場合(例えば,複数のソケットを通して UA と通信するとき)、これらの応答は “競合” を生じさせ、予測不能なふるまいがもたらされ得る。 If a server sends multiple responses containing Set-Cookie headers concurrently to the user agent (e.g., when communicating with the user agent over multiple sockets), these responses create a "race condition" that can lead to unpredictable behavior.

注記: 一部の既存の UA は、2桁表記の年の解釈が他と異なる。 互換性の問題を避けるため、サーバは, [RFC1123] に則り,年の表記に4桁を要する日付形式を利用するべきである。 NOTE: Some existing user agents differ in their interpretation of two-digit years. To avoid compatibility issues, servers SHOULD use the rfc1123-date format, which requires a four-digit year.

注記: 一部の UA は、クッキー内の日付の格納と処理を 32-bit の UNIX time_t 型値として行う。 一部のシステムには, time_t 処理をサポートするライブラリに実装バグがあり、その種の UA では, 2038 年より後の日付が正しく処理されなくなるかもしれない。 NOTE: Some user agents store and process dates in cookies as 32-bit UNIX time_t values. Implementation bugs in the libraries supporting time_t processing on some systems might cause such user agents to process dates after the year 2038 incorrectly.

4.1.2. 意味論(参考)

この節では、 Set-Cookie ヘッダの意味論の概略を述べる。 これらの意味論は、サーバにおけるクッキーの最も一般的な利用を理解するには十分なものである。 全部的な意味論は 5 節 にて述べる。 This section describes simplified semantics of the Set-Cookie header. These semantics are detailed enough to be useful for understanding the most common uses of cookies by servers. The full semantics are described in Section 5.

UA が Set-Cookie ヘッダを受信した際は、そのクッキーを,その属性もひっくるめて格納する。 UA は、後続して HTTP リクエストを生成する際には、適用可能な,まだ失効していないクッキーを Cookie ヘッダに内包させる。 When the user agent receives a Set-Cookie header, the user agent stores the cookie together with its attributes. Subsequently, when the user agent makes an HTTP request, the user agent includes the applicable, non-expired cookies in the Cookie header.

クッキーの属性による指示がない限り、クッキーは、(例えば,下位ドメインではなく)生成元サーバに対してのみ返され,現在のセッションの終了時に失効する( “終了” の意味は UA により定義される)。 UA は、認識できないクッキー属性を,無視する(クッキーまるごと,ではなく)。 Unless the cookie's attributes indicate otherwise, the cookie is returned only to the origin server (and not, for example, to any subdomains), and it expires at the end of the current session (as defined by the user agent). User agents ignore unrecognized cookie attributes (but not the entire cookie).

4.1.2.1. Expires 属性

Expires 属性は、クッキーの最長の存続期間を指示するものであり,クッキーが失効する日時により表現される。 UA には、指定された期日までクッキーを保持することは,要求されない。 実際、 UA は,記憶容量の制限やプライバシー保護の観点から,クッキーを抹消することがある。 The Expires attribute indicates the maximum lifetime of the cookie, represented as the date and time at which the cookie expires. The user agent is not required to retain the cookie until the specified date has passed. In fact, user agents often evict cookies due to memory pressure or privacy concerns.

4.1.2.2. Max-Age 属性

Max-Age 属性もまた、クッキーの最長の存続期間を指示するものであり,クッキーが失効するまでの秒数で表現される。 UA には、指定された期間が経過するまでクッキーを保持することは要求されない。 実際、 UA は,記憶容量の制限やプライバシー保護の観点から,クッキーを抹消することがある。 The Max-Age attribute indicates the maximum lifetime of the cookie, represented as the number of seconds until the cookie expires. The user agent is not required to retain the cookie for the specified duration. In fact, user agents often evict cookies due to memory pressure or privacy concerns.

注記: 一部の既存の UA は Max-Age 属性をサポートしない。 Max-Age 属性をサポートしない UA はこの属性を無視する。 NOTE: Some existing user agents do not support the Max-Age attribute. User agents that do not support the Max-Age attribute ignore the attribute.

クッキーに Max-Age, Expires のいずれの属性も与えられている場合、 Max-Age 属性が優先され,クッキーの有効期限を制御する。 クッキーに Max-AgeExpires のいずれの属性も与えられていない場合、 UA は( UA 定義による) “現在のセッションの終了” まで,クッキーを保持することになる。 If a cookie has both the Max-Age and the Expires attribute, the Max-Age attribute has precedence and controls the expiration date of the cookie. If a cookie has neither the Max-Age nor the Expires attribute, the user agent will retain the cookie until "the current session is over" (as defined by the user agent).

4.1.2.3. Domain 属性

Domain 属性は、クッキーが送信されることになるホストを指定する。 例えば, Domain 属性の値が "example.com" であるなら、 UA は, example.comwww.example.comwww.corp.example.com へ向けて HTTP リクエストを送信する際に、そのクッキーを Cookie ヘッダに内包させることになる( 先頭の %x2E ( "." ) は(もしあれば),その文字が許容されていなくても無視されるが、末尾に %x2E ( "." ) がある場合, UA はその属性を無視することになることに注意)。 サーバが Domain 属性を省略した場合、 UA は生成元サーバに向けてのみクッキーを返すことになる。 The Domain attribute specifies those hosts to which the cookie will be sent. For example, if the value of the Domain attribute is "example.com", the user agent will include the cookie in the Cookie header when making HTTP requests to example.com, www.example.com, and www.corp.example.com. (Note that a leading %x2E ("."), if present, is ignored even though that character is not permitted, but a trailing %x2E ("."), if present, will cause the user agent to ignore the attribute.) If the server omits the Domain attribute, the user agent will return the cookie only to the origin server.

警告: 一部の既存の UA は、 Domain 属性が不在であっても, Domain 属性が存在していて,現在のホスト名を含んでいるかのように扱う。 例えば, example.comDomain 属性の無い Set-Cookie ヘッダを返した場合、これらの UA は,そのクッキーを www.example.com にも誤って送信することになる。 WARNING: Some existing user agents treat an absent Domain attribute as if the Domain attribute were present and contained the current host name. For example, if example.com returns a Set-Cookie header without a Domain attribute, these user agents will erroneously send the cookie to www.example.com as well.

UA は、クッキーの Domain 属性が,そのクッキーの生成元サーバを内包するスコープを指定していない限り、そのクッキーを却下することになる。 例えば、 foo.example.com から受信されたクッキーの Domain 属性の値が "example.com" や "foo.example.com" であれば,そのクッキーは受理されることになる一方、 Domain 属性の値が "bar.example.com" や "baz.foo.example.com" であれば,そのクッキーは受理されないことになる。 The user agent will reject cookies unless the Domain attribute specifies a scope for the cookie that would include the origin server. For example, the user agent will accept a cookie with a Domain attribute of "example.com" or of "foo.example.com" from foo.example.com, but the user agent will not accept a cookie with a Domain attribute of "bar.example.com" or of "baz.foo.example.com".

注記: セキュリティ上の理由から、多くの UA では, public suffix に対応する Domain 属性は却下するように設定されている。 例えば、一部の UA は "com" や "co.uk" などの Domain 属性を却下することになる。 (詳細は 5.3 節 に。) NOTE: For security reasons, many user agents are configured to reject Domain attributes that correspond to "public suffixes". For example, some user agents will reject Domain attributes of "com" or "co.uk". (See Section 5.3 for more information.)

4.1.2.4. Path 属性

それぞれのクッキーのスコープは、その Path 属性で制御される,パスの集合に制限される。 サーバが Path 属性を省略した場合、 UA は, request-uri のパス成分の “ディレクトリ” を,既定の値として利用することになる(詳細は 5.1.4 節 )。 The scope of each cookie is limited to a set of paths, controlled by the Path attribute. If the server omits the Path attribute, the user agent will use the "directory" of the request-uri's path component as the default value. (See Section 5.1.4 for more details.)

UA は request-uri のパス部分がクッキーの Path 属性に合致する(またはその下位ディレクトリになっている)場合にのみ(ここで %x2F ( "/" )はディレクトリ区切子に解釈される)、そのクッキーを HTTP リクエストに内包させることになる。 The user agent will include the cookie in an HTTP request only if the path portion of the request-uri matches (or is a subdirectory of) the cookie's Path attribute, where the %x2F ("/") character is interpreted as a directory separator.

与えられたホストの中で,パスが異なるクッキーを互いに隔離することは,一見 有用であるが、セキュリティは Path 属性に依存できない( 8 節 を見よ)。 Although seemingly useful for isolating cookies between different paths within a given host, the Path attribute cannot be relied upon for security (see Section 8).

4.1.2.5. Secure 属性

Secure 属性は、クッキーのスコープを “セキュア” チャンネル に制限する(“セキュア” の意味は UA により定義される)。 クッキーが Secure 属性を持つとき、 UA は HTTP リクエストがセキュア­チャンネル(概して TLS — HTTP over Transport Layer Security [RFC2818] )を通して伝送される場合にのみ、リクエスト内にそのクッキーを内包させることになる。 The Secure attribute limits the scope of the cookie to "secure" channels (where "secure" is defined by the user agent). When a cookie has the Secure attribute, the user agent will include the cookie in an HTTP request only if the request is transmitted over a secure channel (typically HTTP over Transport Layer Security (TLS) [RFC2818]).

ネットワーク攻撃者からクッキーを保護することは,一見 有用であるが、 Secure 属性が保護するのはクッキーの機密性に限られる。 ネットワーク攻撃者は、セキュアでないチャンネルから Secure クッキーを上書きして,それらの完全性を侵害できる(詳細は 8.6 節 に)。 Although seemingly useful for protecting cookies from active network attackers, the Secure attribute protects only the cookie's confidentiality. An active network attacker can overwrite Secure cookies from an insecure channel, disrupting their integrity (see Section 8.6 for more details).

4.1.2.6. HttpOnly 属性

HttpOnly 属性は、クッキーのスコープを HTTP リクエストに制限する。 特に,この属性は、 UA が “非 HTTP” API (スクリプトにクッキーを公開するウェブブラウザ API など, UA により定義される API )を通して,クッキーへのアクセスを提供する際に、そのクッキーはアクセス対象から除外することを UA に指示する。 The HttpOnly attribute limits the scope of the cookie to HTTP requests. In particular, the attribute instructs the user agent to omit the cookie when providing access to cookies via "non-HTTP" APIs (such as a web browser API that exposes cookies to scripts).

HttpOnly 属性と Secure 属性とは互いに独立であることに注意: 同じクッキーが HttpOnlySecure の両方の属性を持てる。 Note that the HttpOnly attribute is independent of the Secure attribute: a cookie can have both the HttpOnly and the Secure attribute.

4.2. Cookie ヘッダ

4.2.1. 構文

UA は、格納されている一連のクッキーを Cookie ヘッダに入れて,生成元サーバへ送信する。 サーバが 4.1 節 の要件に適合する場合(かつ UA が 5 節 の要件に適合する場合)、 UA は次の文法に適合する Cookie ヘッダを,送信することになる: The user agent sends stored cookies to the origin server in the Cookie header. If the server conforms to the requirements in Section 4.1 (and the user agent conforms to the requirements in Section 5), the user agent will send a Cookie header that conforms to the following grammar:

cookie-header = "Cookie:" OWS cookie-string OWS
cookie-string = cookie-pair *( ";" SP cookie-pair )

4.2.2. 意味論

それぞれの cookie-pair が UA に格納されているクッキーを表現する。 cookie-pair は, UA が Set-Cookie ヘッダ内に受信した cookie-namecookie-value を含む。 Each cookie-pair represents a cookie stored by the user agent. The cookie-pair contains the cookie-name and cookie-value the user agent received in the Set-Cookie header.

クッキーの属性は、 UA からサーバへは返されないことに注意。 特に,サーバは、単独の Cookie ヘッダからは,クッキーが[ いつ失効するのか?/ どのホストに対して有効なのか?/ どのパスに対して有効なのか?/ SecureHttpOnly 属性を伴って設定されたものかどうか? ]を決定できない。 Notice that the cookie attributes are not returned. In particular, the server cannot determine from the Cookie header alone when a cookie will expire, for which hosts the cookie is valid, for which paths the cookie is valid, or whether the cookie was set with the Secure or HttpOnly attributes.

Cookie ヘッダ内の個々のクッキーの意味論については、この文書では定義されない。 これらのクッキーに対するアプリケーション固有の意味論は、サーバごとに指定されることが予期されている。 The semantics of individual cookies in the Cookie header are not defined by this document. Servers are expected to imbue these cookies with application-specific semantics.

クッキーは Cookie ヘッダにて直列化されるが、サーバは,その直列化の順序に依存するべきでない。 特に, Cookie ヘッダ内に同じ名前の2つのクッキーが含まれている場合(例えば、異なる PathDomain 属性を伴って設定されているもの)、サーバは,これらのクッキーがヘッダ内に現れる順序に依存するべきでない。 Although cookies are serialized linearly in the Cookie header, servers SHOULD NOT rely upon the serialization order. In particular, if the Cookie header contains two cookies with the same name (e.g., that were set with different Path or Domain attributes), servers SHOULD NOT rely upon the order in which these cookies appear in the header.

5. UA に課される要件

この節では、 CookieSet-Cookie ヘッダについて、これらの要件を正確に実装する UA が(サーバが 4 節 にて述べた well-behaved profile に適合しなくても),既存のサーバと互換性を保つに足る詳細を指定する。 This section specifies the Cookie and Set-Cookie headers in sufficient detail that a user agent implementing these requirements precisely can interoperate with existing servers (even those that do not conform to the well-behaved profile described in Section 4).

UA は、ここで指定されるものより強い制約を課し得る(例えば,セキュリティ向上のための)。 しかしながら,経験則から、その種の厳密性は既存サーバとの相互運用性を犠牲にする見込みも高くなる。 A user agent could enforce more restrictions than those specified herein (e.g., for the sake of improved security); however, experiments have shown that such strictness reduces the likelihood that a user agent will be able to interoperate with existing servers.

5.1. 下位成分アルゴリズム

この節では、 CookieSet-Cookie ヘッダに含まれる特定の下位成分を処理するために UA が利用する,いくつかのアルゴリズムを規定する。 【これらのアルゴリズムは、後続の節から参照される。】 This section defines some algorithms used by user agents to process specific subcomponents of the Cookie and Set-Cookie headers.

5.1.1. 日付

UA は,文字列 cookie-date を構文解析する際に、次のアルゴリズムと等価なアルゴリズムを利用しなければならない( アルゴリズムの中の一連の真偽値フラグ( found-time, found-day-of-month, found-month, found-year )の初期値は false であることに注意): The user agent MUST use an algorithm equivalent to the following algorithm to parse a cookie-date. Note that the various boolean flags defined as a part of the algorithm (i.e., found-time, found-day-of-month, found-month, found-year) are initially "not set".

  1. 下の文法を用いて, cookie-datedate-token のリストに分割する。 Using the grammar below, divide the cookie-date into date-tokens.

    cookie-date     = *delimiter date-token-list *delimiter
    date-token-list = date-token *( 1*delimiter date-token )
    date-token      = 1*non-delimiter
    
    delimiter       = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E
    non-delimiter   = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA / %x7F-FF
    non-digit       = %x00-2F / %x3A-FF
    
    day-of-month    = 1*2DIGIT [ non-digit *OCTET ]
    month           = ( "jan" / "feb" / "mar" / "apr" /
                        "may" / "jun" / "jul" / "aug" /
                        "sep" / "oct" / "nov" / "dec" ) *OCTET
    year            = 2*4DIGIT [ non-digit *OCTET ]
    time            = hms-time [ non-digit *OCTET ]
    hms-time        = time-field ":" time-field ":" time-field
    time-field      = 1*2DIGIT
    

    day-of-month, year, time の右辺の [ non-digit *OCTET ] を括る角括弧(任意選択を表す)は、 正誤表( Verified )による修正(元々は丸括弧: ( non-digit *OCTET ) )。 】

  2. リストの中の各 date-token を,それらが cookie-date 内に現れる順に処理する: Process each date-token sequentially in the order the date-tokens appear in the cookie-date:

    1. found-time フラグ = false, かつ date-token が生成規則 time に合致するならば: found-time フラグ ← true
      hour-value, minute-value, second-value ← それぞれ順に date-token の中の数字が表す数値;
      残りの段を飛ばして次の date-token の処理へ。
      If the found-time flag is not set and the token matches the time production, set the found-time flag and set the hour-value, minute-value, and second-value to the numbers denoted by the digits in the date-token, respectively. Skip the remaining sub-steps and continue to the next date-token.

    2. found-day-of-month フラグ = false, かつ date-token が生成規則 day-of-month に合致するならば: found-day-of-month フラグ ← true
      day-of-month-valuedate-token が表す数値;
      残りの段を飛ばして次の date-token の処理へ。
      If the found-day-of-month flag is not set and the date-token matches the day-of-month production, set the found-day-of-month flag and set the day-of-month-value to the number denoted by the date-token. Skip the remaining sub-steps and continue to the next date-token.

    3. found-month フラグ = false, かつ date-token が生成規則 month に合致するならば: found-month フラグ ← true
      month-valuedate-token が表す月;
      残りの段を飛ばして次の date-token の処理へ。
      If the found-month flag is not set and the date-token matches the month production, set the found-month flag and set the month-value to the month denoted by the date-token. Skip the remaining sub-steps and continue to the next date-token.

    4. found-year フラグ = false, かつ date-token が生成規則 year に合致するならば: found-year フラグ ← true
      year-valuedate-token が表す数値;
      残りの段を飛ばして次の date-token の処理へ。
      If the found-year flag is not set and the date-token matches the year production, set the found-year flag and set the year-value to the number denoted by the date-token. Skip the remaining sub-steps and continue to the next date-token.

  3. year-value ≥ 70, かつ year-value ≤ 99 ならば: year-value に 1900 を加える。 If the year-value is greater than or equal to 70 and less than or equal to 99, increment the year-value by 1900.

  4. year-value ≥ 0, かつ year-value ≤ 69 ならば: year-value に 2000 を加える If the year-value is greater than or equal to 0 and less than or equal to 69, increment the year-value by 2000.

    注記: 一部の既存の UA は、2桁表記の年の解釈が他と異なる。 NOTE: Some existing user agents interpret two-digit years differently.

  5. 次のいずれかが成立する場合、この手続きを中止して, cookie-date の構文解析を失敗させる: Abort these steps and fail to parse the cookie-date if:

    • found-day-of-month, found-month, found-year, found-time のうち,いずれかのフラグが false at least one of the found-day-of-month, found-month, found-year, or found-time flags is not set,

    • day-of-month-value < 1, または day-of-month-value > 31 the day-of-month-value is less than 1 or greater than 31,

    • year-value < 1601 the year-value is less than 1601,

    • hour-value > 23 the hour-value is greater than 23,

    • minute-value > 59 the minute-value is greater than 59, or

    • second-value > 59 the second-value is greater than 59.

    (うるう秒はこの構文では表現できないことに注意。) (Note that leap seconds cannot be represented in this syntax.)

  6. parsed-cookie-date ← UTC (協定世界時)[ 年: year-value, 月: month-value, 日: day-of-month-value, 時: hour-value, 分: minute-value, 秒: second-value ]で与えられる日時。 そのような日付が存在しない場合、この手続きを中止して, cookie-date の構文解析を失敗させる。 Let the parsed-cookie-date be the date whose day-of-month, month, year, hour, minute, and second (in UTC) are the day-of-month-value, the month-value, the year-value, the hour-value, the minute-value, and the second-value, respectively. If no such date exists, abort these steps and fail to parse the cookie-date.

  7. このアルゴリズムの結果として, parsed-cookie-date を返す。 Return the parsed-cookie-date as the result of this algorithm.

5.1.2. 正準化ホスト名

ホスト名の 正準化 とは、次のアルゴリズムにより生成される文字列である: A canonicalized host name is the string generated by the following algorithm:

  1. ホスト名を個々のドメイン名ラベルの並びに変換する。 Convert the host name to a sequence of individual domain name labels.

  2. Non-Reserved LDH ( NR-LDH )ラベルでない各ラベルを,次のうち適切な方(この仕様の 6.3 節 )に変換する:

    Convert each label that is not a Non-Reserved LDH (NR-LDH) label, to an A-label (see Section 2.3.2.1 of [RFC5890] for the former and latter), or to a "punycode label" (a label resulting from the "ToASCII" conversion in Section 4 of [RFC3490]), as appropriate (see Section 6.3 of this specification).

  3. 結果のラベル並びを、区切り文字 %x2E ( "." )で連結する。 Concatenate the resulting labels, separated by a %x2E (".") character.

5.1.3. ドメイン照合

文字列 は、次のいずれかの条件が満たされるとき,与えられた ドメイン文字列ドメイン合致する とされる: A string domain-matches a given domain string if at least one of the following conditions hold:

  • ドメイン文字列文字列 は一致する。 (この時点では、 ドメイン文字列文字列 のいずれも,小文字に正準化されていることに注意。) The domain string and the string are identical. (Note that both the domain string and the string will have been canonicalized to lower case at this point.)

  • 次のいずれの条件も満たされる: All of the following conditions hold:

    • ドメイン文字列文字列 の尾部に一致する。 The domain string is a suffix of the string.

    • 文字列 の中で, ドメイン文字列 に含まれない部分 ]の最後の文字 = %x2E ( "." )。 The last character of the string that is not included in the domain string is a %x2E (".") character.

    • 文字列 はホスト名である(すなわち, IP アドレスではない)。 The string is a host name (i.e., not an IP address).

5.1.4. パスとパス合致

UA は クッキーの default-path を算出する際に、次と等価なアルゴリズムを利用しなければならない The user agent MUST use an algorithm equivalent to the following algorithm to compute the default-path of a cookie:

  1. uri-pathrequest-uri のパス(パスが含まれていない場合は空)

    例えば request-uri が,パス(およびオプションのクエリ文字列)のみを含むならば, uri-path は( %x3F ( "?" )やクエリ文字列を除いた)そのパスになり、全部的な絶対 URI であるならば, uri-path はその URI のパス成分になる。

    Let uri-path be the path portion of the request-uri if such a portion exists (and empty otherwise). For example, if the request-uri contains just a path (and optional query string), then the uri-path is that path (without the %x3F ("?") character or query string), and if the request-uri contains a full absoluteURI, the uri-path is the path component of that URI.

  2. uri-path = 空, または uri-path の最初の文字が %x2F ( "/" )でないならば: %x2F ( "/" )を返して終了。 If the uri-path is empty or if the first character of the uri-path is not a %x2F ("/") character, output %x2F ("/") and skip the remaining steps.

  3. uri-path に含まれる %x2F ( "/" )が高々1個ならば: %x2F ( "/" )を返して終了。 If the uri-path contains no more than one %x2F ("/") character, output %x2F ("/") and skip the remaining step.

  4. uri-path の最初の文字から最後の %x2F ( "/" ) の直前までの文字列を返す。 Output the characters of the uri-path from the first character up to, but not including, the right-most %x2F ("/").

文字列 request-path は、次のいずれかの条件が満たされるとき,与えられた文字列 cookie-pathパス合致する とされる: A request-path path-matches a given cookie-path if at least one of the following conditions holds:

  • cookie-pathrequest-path は一致する The cookie-path and the request-path are identical.

    正誤表による注釈あり( Held for Document Update ):】 これは RFC 3986 によるパス成分の等価性の規則とは,異なることに注意 — 従って、その意味で等価な2つのパスは,異なるクッキーを持つことがあり得る。 Note that this differs from the rules in RFC 3986 for equivalence of the path component, and hence two equivalent paths can have different cookies.

  • cookie-pathrequest-path の頭部に一致する, かつ cookie-path の最後の文字が %x2F ( "/" )である The cookie-path is a prefix of the request-path, and the last character of the cookie-path is %x2F ("/").

  • cookie-pathrequest-path の頭部に一致する, かつ request-path の中で cookie-path に含まれない部分の最初の文字が %x2F ( "/" )である。 The cookie-path is a prefix of the request-path, and the first character of the request-path that is not included in the cookie-path is a %x2F ("/") character.

5.2. Set-Cookie ヘッダ

UA は、 HTTP 応答にて受信された Set-Cookie ヘッダを,まるごと無視してよい。 例えば UA は、 “第三者主体” へのリクエストに対する応答による,クッキーの設定に対し、その遮断を望むかもしれない( 7.1 節 を見よ)。 When a user agent receives a Set-Cookie header field in an HTTP response, the user agent MAY ignore the Set-Cookie header field in its entirety. For example, the user agent might wish to block responses to "third-party" requests from setting cookies (see Section 7.1).

UA は Set-Cookie ヘッダをまるごと無視しない場合、 Set-Cookie ヘッダの値を set-cookie-string として,以下で規定されるように,構文解析しなければならない If the user agent does not ignore the Set-Cookie header field in its entirety, the user agent MUST parse the field-value of the Set-Cookie header field as a set-cookie-string (defined below).

注記: 下のアルゴリズムは 4.1 節 の文法よりも寛容である。 例えば、アルゴリズムでは,クッキーの名前と値から頭部と尾部の空白類が取り除かれる(内部の空白類は維持される)一方、 4.1 節 の文法では,それらの空白類は禁止されている。 UA は、 4 節 の推奨に従わないサーバとの互換性をとるために,このアルゴリズムを利用する。 NOTE: The algorithm below is more permissive than the grammar in Section 4.1. For example, the algorithm strips leading and trailing whitespace from the cookie name and value (but maintains internal whitespace), whereas the grammar in Section 4.1 forbids whitespace in these positions. User agents use this algorithm so as to interoperate with servers that do not follow the recommendations in Section 4.

【 記述を簡潔にするため、当訳では,次を定義する(これに伴い、アルゴリズムの中の文字 ";" の処理位置に変更を加えているが、得られる結果に差異はない): 】

下のアルゴリズムにおいて、文字列 S に対する文字 c による 分割 とは、次で与えられる2個の文字列の(順序付けられた)組である:

  1. S の先頭から連続する, c でない文字からなる,最長の文字列( S が空,または S の先頭が c であれば,空)
  2. 前段の残りの部分の文字列から,(もしあれば)先頭の c は除外した文字列(残りの部分が空, または c 1個のみであれば,空)

UA は set-cookie-string を構文解析する際に、次と等価なアルゴリズムを利用しなければならない A user agent MUST use an algorithm equivalent to the following algorithm to parse a "set-cookie-string":

  1. name-value-pair, unparsed-attributes ]← set-cookie-string に対する文字 %x3B ( ";" )による分割 If the set-cookie-string contains a %x3B (";") character: The name-value-pair string consists of the characters up to, but not including, the first %x3B (";"), and the unparsed-attributes consist of the remainder of the set-cookie-string (including the %x3B (";") in question). Otherwise: The name-value-pair string consists of all the characters contained in the set-cookie-string, and the unparsed-attributes is the empty string.

  2. name-value-pair に文字 %x3D ( "=" )が含まれていないならば: set-cookie-string をまるごと無視する。 If the name-value-pair string lacks a %x3D ("=") character, ignore the set-cookie-string entirely.

  3. cookie-name, cookie-value ]← name-value-pair に対する文字 %x3D ( "=" )による分割 The (possibly empty) name string consists of the characters up to, but not including, the first %x3D ("=") character, and the (possibly empty) value string consists of the characters after the first %x3D ("=") character.

  4. cookie-namecookie-value から頭部と尾部の WSP 文字­並びを取り除く。 Remove any leading or trailing WSP characters from the name string and the value string.

  5. cookie-name = 空,ならば: set-cookie-string をまるごと無視する。 If the name string is empty, ignore the set-cookie-string entirely.

  6. cookie-name が名前­文字列, cookie-value が値­文字列になる。 The cookie-name is the name string, and the cookie-value is the value string.

UA は上の unparsed-attributes を構文解析する際に、次と等価なアルゴリズムを利用しなければならない The user agent MUST use an algorithm equivalent to the following algorithm to parse the unparsed-attributes:

  1. cookie-attribute-list ← 空リスト ([ 名前, 値 ]による組で表現される属性からなるリスト)

  2. 以下を繰り返し実行する:

    1. unparsed-attributes = 空,ならば: 繰り返しを終了。 If the unparsed-attributes string is empty, skip the rest of these steps.

    2. cookie-av, unparsed-attributes ]← unparsed-attributes に対する文字 %x3B ( ";" )による分割 Discard the first character of the unparsed-attributes (which will be a %x3B (";") character). If the remaining unparsed-attributes contains a %x3B (";") character: Consume the characters of the unparsed-attributes up to, but not including, the first %x3B (";") character. Otherwise: Consume the remainder of the unparsed-attributes. Let the cookie-av string be the characters consumed in this step.

    3. attribute-name, attribute-value ]← cookie-av に対する文字 %x3D ( "=" )による分割 If the cookie-av string contains a %x3D ("=") character: The (possibly empty) attribute-name string consists of the characters up to, but not including, the first %x3D ("=") character, and the (possibly empty) attribute-value string consists of the characters after the first %x3D ("=") character. Otherwise: The attribute-name string consists of the entire cookie-av string, and the attribute-value string is empty.

    4. attribute-name および attribute-value から、頭部と尾部の WSP 文字­並びを取り除く。 Remove any leading or trailing WSP characters from the attribute-name string and the attribute-value string.

    5. この節の後続の各 下位節の要件に従って, attribute-nameattribute-value を処理する 【 その結果, cookie-attribute-list に属性が追加される 】 — ただし、 attribute-name が下位節のどのアルゴリズムからも認識されない属性は無視する。 Process the attribute-name and attribute-value according to the requirements in the following subsections. (Notice that attributes with unrecognized attribute-names are ignored.)

    6. 次の反復へ。 Return to Step 1 of this algorithm.

UA が set-cookie-string の構文解析を終えたとき、 UA は request-uri から[ 名前: cookie-name, 値: cookie-value, 属性リスト: cookie-attribute-list ]を伴う クッキーを受信した とされる。 (クッキーの受信により発生する追加の要件については 5.3 節 にて述べる。) When the user agent finishes parsing the set-cookie-string, the user agent is said to "receive a cookie" from the request-uri with name cookie-name, value cookie-value, and attributes cookie-attribute-list. (See Section 5.3 for additional requirements triggered by receiving a cookie.)

5.2.1. Expires 属性

UA は、[ attribute-name が文字列 "Expires" に 文字大小無視で合致する ]ような cookie-av を,次の様に処理しなければならない If the attribute-name case-insensitively matches the string "Expires", the user agent MUST process the cookie-av as follows.

  1. expiry-time attribute-valuecookie-date として構文解析した結果( 5.1.1 節 )。 Let the expiry-time be the result of parsing the attribute-value as cookie-date (see Section 5.1.1).

  2. 構文解析に失敗した場合、その cookie-av を無視する。 If the attribute-value failed to parse as a cookie date, ignore the cookie-av.

  3. expiry-time が UA が表現し得る最も未来の日付より後ならば: UA は expiry-time を,表現し得る最も未来の日付に置換してもよい If the expiry-time is later than the last date the user agent can represent, the user agent MAY replace the expiry-time with the last representable date.

  4. expiry-time が UA が表現し得る最も過去の日付より前ならば: UA は expiry-time を,表現し得る最も過去の日付に置換してもよい If the expiry-time is earlier than the earliest date the user agent can represent, the user agent MAY replace the expiry-time with the earliest representable date.

  5. [ 名前: Expires, 値: expiry-time ]の属性を cookie-attribute-list に追加する。 Append an attribute to the cookie-attribute-list with an attribute-name of Expires and an attribute-value of expiry-time.

5.2.2. Max-Age 属性

UA は、[ attribute-name が文字列 "Max-Age" に 文字大小無視で合致する ]ような cookie-av を,次の様に処理しなければならない If the attribute-name case-insensitively matches the string "Max-Age", the user agent MUST process the cookie-av as follows.

  1. attribute-value の最初の文字が DIGIT でも文字 "-" でもないならば: その cookie-av を無視する。 If the first character of the attribute-value is not a DIGIT or a "-" character, ignore the cookie-av.

  2. attribute-value の残りの部分に非 DIGIT 文字が含まれるならば: その cookie-av を無視する。 If the remainder of attribute-value contains a non-DIGIT character, ignore the cookie-av.

  3. delta-secondsattribute-value を整数に変換した結果。 Let delta-seconds be the attribute-value converted to an integer.

  4. delta-seconds ≤ 0 ならば: expiry-time ← UA が表現し得る最も過去の日付。 他の場合: expiry-time ← 現在の日時に delta-seconds 秒を加えた日時。 If delta-seconds is less than or equal to zero (0), let expiry-time be the earliest representable date and time. Otherwise, let the expiry-time be the current date and time plus delta-seconds seconds.

  5. [ 名前: Max-Age, 値: expiry-time ]の属性を cookie-attribute-list に追加する。 Append an attribute to the cookie-attribute-list with an attribute-name of Max-Age and an attribute-value of expiry-time.

5.2.3. Domain 属性

UA は、[ attribute-name が文字列 "Domain" に 文字大小無視で合致する ]ような cookie-av を,次の様に処理しなければならない If the attribute-name case-insensitively matches the string "Domain", the user agent MUST process the cookie-av as follows.

attribute-value = 空,の場合のふるまいは未定義である。 しかしながら、 UA は cookie-av をまるごと無視するべきである。 If the attribute-value is empty, the behavior is undefined. However, the user agent SHOULD ignore the cookie-av entirely.

  1. cookie-domain の最初の文字 = %x2E ( "." ),ならば: cookie-domainattribute-value からその最初の %x2E ( "." )を取り除いた値。 他の場合: cookie-domainattribute-value If the first character of the attribute-value string is %x2E ("."): Let cookie-domain be the attribute-value without the leading %x2E (".") character. Otherwise: Let cookie-domain be the entire attribute-value.

  2. cookie-domain を小文字に変換する。 Convert the cookie-domain to lower case.

  3. [ 名前: Domain, 値: cookie-domain ]の属性を cookie-attribute-list に追加する。 Append an attribute to the cookie-attribute-list with an attribute-name of Domain and an attribute-value of cookie-domain.

5.2.4. Path 属性

UA は、[ attribute-name が文字列 "Path" に 文字大小無視で合致する ]ような cookie-av を,次の様に処理しなければならない If the attribute-name case-insensitively matches the string "Path", the user agent MUST process the cookie-av as follows.

  1. attribute-value = 空,または attribute-value の最初の文字 ≠ %x2F ( "/" ),ならば: cookie-pathdefault-path 他の場合: cookie-pathattribute-value If the attribute-value is empty or if the first character of the attribute-value is not %x2F ("/"): Let cookie-path be the default-path. Otherwise: Let cookie-path be the attribute-value.

  2. [ 名前: Path, 値: cookie-path ]の属性を cookie-attribute-list に追加する。 Append an attribute to the cookie-attribute-list with an attribute-name of Path and an attribute-value of cookie-path.

5.2.5. Secure 属性

UA は、[ attribute-name が文字列 "Secure" に 文字大小無視で合致する ]ような cookie-av に対しては, [ 名前: Secure, 値: 空 ]の属性を cookie-attribute-list に追加しなければならない If the attribute-name case-insensitively matches the string "Secure", the user agent MUST append an attribute to the cookie-attribute-list with an attribute-name of Secure and an empty attribute-value.

5.2.6. HttpOnly 属性

UA は、[ attribute-name が文字列 "HttpOnly" に 文字大小無視で合致する ]ような cookie-av に対しては, [ 名前: HttpOnly , 値: 空 ]の属性を cookie-attribute-list に追加しなければならない If the attribute-name case-insensitively matches the string "HttpOnly", the user agent MUST append an attribute to the cookie-attribute-list with an attribute-name of HttpOnly and an empty attribute-value.

5.3. 保管モデル

UA は各クッキーに対し,次のフィールドを格納する:

  • name
  • value
  • expiry-time
  • domain
  • path
  • creation-time
  • last-access-time
  • persistent-flag
  • host-only-flag
  • secure-only-flag
  • http-only-flag

The user agent stores the following fields about each cookie: name, value, expiry-time, domain, path, creation-time, last-access-time, persistent-flag, host-only-flag, secure-only-flag, and http-only-flag.

UA は、 request-uri から[ 名前: cookie-name, 値: cookie-value, 属性リスト: cookie-attribute-list ]を伴う クッキーを受信した 際に、そのクッキーを,次のように処理しなければならない When the user agent "receives a cookie" from a request-uri with name cookie-name, value cookie-value, and attributes cookie-attribute-list, the user agent MUST process the cookie as follows:

  1. UA は、受信されたクッキーをまるごと無視してよい。 例えば、 UA は, “第三者主体” からの応答で受信されるクッキーの遮断を望んだり、一定サイズを超えるクッキーの格納を望まないことがある。 A user agent MAY ignore a received cookie in its entirety. For example, the user agent might wish to block receiving cookies from "third-party" responses or the user agent might not wish to store cookies that exceed some size.

  2. 新たなクッキー new-cookie を作成し、そのフィールドを次の様に設定する: namecookie-name
    valuecookie-value
    creation-time ← 現在の日時;
    last-access-time ← 現在の日時
    Create a new cookie with name cookie-name, value cookie-value. Set the creation-time and the last-access-time to the current date and time.

  3. cookie-attribute-list に 名前: "Max-Age" の属性が含まれているならば: new-cookiepersistent-flagtrue
    new-cookieexpiry-timecookie-attribute-list の中で、名前: "Max-Age" なる,最後の属性の値。
    If the cookie-attribute-list contains an attribute with an attribute-name of "Max-Age": Set the cookie's persistent-flag to true. Set the cookie's expiry-time to attribute-value of the last attribute in the cookie-attribute-list with an attribute-name of "Max-Age".

    他の場合, cookie-attribute-list に 名前: "Expires" の属性が含まれている(かつ 名前: "Max-Age" なる属性は含まれていない)ならば: new-cookiepersistent-flagtrue
    new-cookieexpiry-timecookie-attribute-list の中で、名前: "Expires" なる,最後の属性の値。
    Otherwise, if the cookie-attribute-list contains an attribute with an attribute-name of "Expires" (and does not contain an attribute with an attribute-name of "Max-Age"): Set the cookie's persistent-flag to true. Set the cookie's expiry-time to attribute-value of the last attribute in the cookie-attribute-list with an attribute-name of "Expires".

    他の場合: new-cookiepersistent-flagfalse
    new-cookieexpiry-time ← UA が表現し得る最も未来の日付。
    Otherwise: Set the cookie's persistent-flag to false. Set the cookie's expiry-time to the latest representable date.

  4. cookie-attribute-list に 名前: "Domain" の属性が含まれているならば: domain-attributecookie-attribute-list の中で、名前: "Domain" なる,最後の属性の値。 If the cookie-attribute-list contains an attribute with an attribute-name of "Domain": Let the domain-attribute be the attribute-value of the last attribute in the cookie-attribute-list with an attribute-name of "Domain".

    他の場合: domain-attribute ← 空文字列。 Otherwise: Let the domain-attribute be the empty string.

  5. UA が public suffix を却下するように設定されていて,かつ domain-attributepublic suffix であるならば: If the user agent is configured to reject "public suffixes" and the domain-attribute is a public suffix:

    1. domain-attribute正準化された request-host と一致するならば: domain-attribute ← 空文字列。 If the domain-attribute is identical to the canonicalized request-host: Let the domain-attribute be the empty string.

    2. 他の場合: この手続きを中止する(クッキーをまるごと無視する)。 Otherwise: Ignore the cookie entirely and abort these steps.

    注記: "com", "co.uk", "pvt.k12.wy.us" などの, public suffix は、 public registry にて管理されているドメインである。 この段は、 attacker.com (攻撃者)が値 "com" の Domain 属性を伴うクッキーを設定することにより, "example.com" の完全性を侵害することを防止するために本質的である。 あいにく、 public suffix の集合(レジストリにより管理されているドメイン — "registry controlled domains" としても知られている)は、年々変化している。 引き合うのであれば、 UA は Mozilla project : <http://publicsuffix.org/> にて維持管理されているもののような,日々更新される public suffix リストを利用するべきである。 【「年々」「日々」:雰囲気訳。実際の変化頻度を確かめたわけではない。例えば毎分, 毎秒レベルの頻度(になる)かもしれない。】 NOTE: A "public suffix" is a domain that is controlled by a public registry, such as "com", "co.uk", and "pvt.k12.wy.us". This step is essential for preventing attacker.com from disrupting the integrity of example.com by setting a cookie with a Domain attribute of "com". Unfortunately, the set of public suffixes (also known as "registry controlled domains") changes over time. If feasible, user agents SHOULD use an up-to-date public suffix list, such as the one maintained by the Mozilla project at <http://publicsuffix.org/>.

  6. domain-attribute ≠ 空,ならば: If the domain-attribute is non-empty:

    1. request-host正準化した結果が domain-attributeドメイン合致 しないならば: この手続きを中止する(クッキーをまるごと無視する)。 If the canonicalized request-host does not domain-match the domain-attribute: Ignore the cookie entirely and abort these steps.

    2. new-cookiehost-only-flagfalse
      new-cookiedomaindomain-attribute Otherwise: Set the cookie's host-only-flag to false. Set the cookie's domain to the domain-attribute.

    他の場合: new-cookiehost-only-flagtrue
    new-cookiedomainrequest-host正準化した結果
    Otherwise: Set the cookie's host-only-flag to true. Set the cookie's domain to the canonicalized request-host.

  7. cookie-attribute-list に 名前: "Path" の属性が含まれているならば: new-cookiepath ← それらのうち,最後のものの値。 他の場合: new-cookiepathrequest-uridefault-path If the cookie-attribute-list contains an attribute with an attribute-name of "Path", set the cookie's path to attribute-value of the last attribute in the cookie-attribute-list with an attribute-name of "Path". Otherwise, set the cookie's path to the default-path of the request-uri.

  8. new-cookiesecure-only-flagcookie-attribute-list に名前: "Secure" の属性が含まれているならば true, そうでなければ false If the cookie-attribute-list contains an attribute with an attribute-name of "Secure", set the cookie's secure-only-flag to true. Otherwise, set the cookie's secure-only-flag to false.

  9. new-cookiehttp-only-flagcookie-attribute-list に名前: "HttpOnly" の属性が含まれているならば true, そうでなければ false If the cookie-attribute-list contains an attribute with an attribute-name of "HttpOnly", set the cookie's http-only-flag to true. Otherwise, set the cookie's http-only-flag to false.

  10. クッキーが “非 HTTP” API から受信されていて, かつ new-cookiehttp-only-flagtrue ならば: この手続きを中止する(クッキーをまるごと無視する)。 If the cookie was received from a "non-HTTP" API and the cookie's http-only-flag is set, abort these steps and ignore the cookie entirely.

  11. クッキー保管庫に new-cookie と同じ name, domain, path のクッキーがある場合: If the cookie store contains a cookie with the same name, domain, and path as the newly created cookie:

    1. old-cookie ← その既存のクッキー。 (このアルゴリズムは、そのようなクッキーが高々1個に限られる,という不変則を、常に保つことに注意。) Let old-cookie be the existing cookie with the same name, domain, and path as the newly created cookie. (Notice that this algorithm maintains the invariant that there is at most one such cookie.)

    2. クッキーが “非 HTTP” API から受信されていて, かつ old-cookiehttp-only-flagtrue ならば: この手続きを中止する(クッキーをまるごと無視する)。 If the newly created cookie was received from a "non-HTTP" API and the old-cookie's http-only-flag is set, abort these steps and ignore the newly created cookie entirely.

    3. new-cookiecreation-timeold-cookiecreation-time に合致するように,更新。 Update the creation-time of the newly created cookie to match the creation-time of the old-cookie.

    4. クッキー保管庫から old-cookie を取り除く。 Remove the old-cookie from the cookie store.

  12. new-cookie をクッキー保管庫に挿入。 Insert the newly created cookie into the cookie store.

クッキーが過去の有効期限を持つとき、そのクッキーは 失効した ( “expired” )とされる。 A cookie is "expired" if the cookie has an expiry date in the past.

UA は、クッキー保管庫に 失効した クッキーが存在する場合は,いつでも、それら 失効した クッキーすべてをクッキー保管庫から抹消しなければならない The user agent MUST evict all expired cookies from the cookie store if, at any time, an expired cookie exists in the cookie store.

UA は、 domain フィールドを共有するクッキーの総数が,実装定義の何らかの上限(例えば 50 クッキー)を超えたときは,いつでも、クッキー保管庫から “超過クッキーを除去” してよい At any time, the user agent MAY "remove excess cookies" from the cookie store if the number of cookies sharing a domain field exceeds some implementation-defined upper bound (such as 50 cookies).

UA は、クッキー保管庫の容量が,実装定義の何らかの上限(例えば 3000 クッキー)を超えたときは,いつでも、クッキー保管庫から “超過クッキーを除去” してよい At any time, the user agent MAY "remove excess cookies" from the cookie store if the cookie store exceeds some predetermined upper bound (such as 3000 cookies).

UA が,クッキー保管庫から超過クッキーを除去するときは、次の優先順位により,クッキーを抹消しなければならない When the user agent removes excess cookies from the cookie store, the user agent MUST evict cookies in the following priority order:

  1. 失効したクッキー。 Expired cookies.

  2. 同じ domain フィールドを共有するクッキーのうち、決められたクッキー数を超えた分。 Cookies that share a domain field with more than a predetermined number of other cookies.

  3. すべてのクッキー。 All cookies.

2つのクッキーが同じ除去優先度にある場合、 UA は last-access-time が最も過去のクッキーを抹消しなければならない If two cookies have the same removal priority, the user agent MUST evict the cookie with the earliest last-access date first.

UA は、現在のセッションが終了した際に( “セッションの終了” は UA により定義される)、クッキー保管庫から persistent-flagfalse なる,すべてのクッキーを除去しなければならない When "the current session is over" (as defined by the user agent), the user agent MUST remove from the cookie store all cookies with the persistent-flag set to false.

5.4. Cookie ヘッダ

UA は格納されているクッキーを Cookie HTTP リクエスト­ヘッダに内包させる。 The user agent includes stored cookies in the Cookie HTTP request header.

UA は HTTP リクエストを生成する際に、複数の Cookie ヘッダを添付してはならない When the user agent generates an HTTP request, the user agent MUST NOT attach more than one Cookie header field.

UA は Cookie ヘッダをまるごと省略してよい。 例えば、 UA は “第三者主体” リクエストの間,クッキーの送信をクッキーの設定から遮断することを望むかもしれない( 7.1 節 を見よ)。 A user agent MAY omit the Cookie header in its entirety. For example, the user agent might wish to block sending cookies during "third-party" requests from setting cookies (see Section 7.1).

UA は HTTP リクエストに Cookie ヘッダを添付する際に、(下で定義される) cookie-string をヘッダの値として,送信しなければならない If the user agent does attach a Cookie header field to an HTTP request, the user agent MUST send the cookie-string (defined below) as the value of the header field.

UA はクッキー保管庫と request-uri から cookie-string を算出する際に、次と等価なアルゴリズムを利用しなければならない The user agent MUST use an algorithm equivalent to the following algorithm to compute the "cookie-string" from a cookie store and a request-uri:

  1. cookie-list を、クッキー保管庫の中で,次の要件すべてを満たすクッキーの集合とする: Let cookie-list be the set of cookies from the cookie store that meets all of the following requirements:

    • [ クッキーの host-only-flagtrue, かつ request-host正準化した結果 = クッキーの domain ], または[ クッキーの host-only-flagfalse, かつ request-host正準化した結果が クッキーの domainドメイン合致する ]。 Either: The cookie's host-only-flag is true and the canonicalized request-host is identical to the cookie's domain. Or: The cookie's host-only-flag is false and the canonicalized request-host domain-matches the cookie's domain.

    • request-uri のパスがクッキーの pathパス合致する The request-uri's path path-matches the cookie's path.

    • クッキーの secure-only-flagtrue ならば、 request-uri のスキームは( UA 定義の)“セキュア” プロトコルを示すものでなければならない。 If the cookie's secure-only-flag is true, then the request-uri's scheme must denote a "secure" protocol (as defined by the user agent).

      注記: 何をもって “セキュア” プロトコルとするかは、この文書では定義されない。 概して、 UA は,プロトコルが SSL や TLS などのトランスポート層のセキュリティを利用するものであれば、それをセキュアであるものとみなす。 例えば、ほとんどの UA は "https" をセキュア­プロトコルを示すスキームと見なす。 NOTE: The notion of a "secure" protocol is not defined by this document. Typically, user agents consider a protocol secure if the protocol makes use of transport-layer security, such as SSL or TLS. For example, most user agents consider "https" to be a scheme that denotes a secure protocol.

    • http-only-flagtrue のクッキーについては、 cookie-string が( UA により定義される) “非 HTTP” API により生成されているクッキーは,除外する。 If the cookie's http-only-flag is true, then exclude the cookie if the cookie-string is being generated for a "non-HTTP" API (as defined by the user agent).

  2. UA は cookie-list を次を満たす順序に整列させるべきである: The user agent SHOULD sort the cookie-list in the following order:

    • より長いパスを伴うクッキーは,より短いパスを伴うものより前に位置する Cookies with longer paths are listed before cookies with shorter paths.

    • path フィールドの長さが等しいクッキーの中では、 creation-time がより過去のものが,より未来のものより前に位置する Among cookies that have equal-length path fields, cookies with earlier creation-times are listed before cookies with later creation-times.

    注記: すべての UA が cookie-list をこの順序に整列させるわけではないが、この順序は,この文書が書かれた時点での慣行を反映するものである。 歴史的には、(誤って)この順序に依存するサーバが存在してきた。 NOTE: Not all user agents sort the cookie-list in this order, but this order reflects common practice when this document was written, and, historically, there have been servers that (erroneously) depended on this order.

  3. cookie-list の各クッキーの last-access-time を,現在の日時に更新する。 Update the last-access-time of each cookie in the cookie-list to the current date and time.

  4. cookie-list の各クッキーを順に処理して, cookie-string に直列化する: Serialize the cookie-list into a cookie-string by processing each cookie in the cookie-list in order:

    1. [ クッキーの name, %x3D ( "=" ), クッキーの value ]を順に出力。 Output the cookie's name, the %x3D ("=") character, and the cookie's value.

    2. cookie-list に未処理のクッキーが残っているなら[ 文字 %x3B, 文字 %x20 ]( "; " )を出力。 If there is an unprocessed cookie in the cookie-list, output the characters %x3B and %x20 ("; ").

注記: その名称に反し、 cookie-string は,実際は(普通の意味の)文字の並びではなく,オクテットの並びである。 UA は、 cookie-string (またはその成分)を(例えば,利用者に表示する目的で)文字の並びに変換する際に,そのオクテット並びの復号に UTF-8 文字­符号化方式 [RFC3629] の利用を試みることも考えられる。 しかしながら,すべてのオクテット並びが妥当な UTF-8 になるとは限らないので、この復号は失敗する可能性もある。 NOTE: Despite its name, the cookie-string is actually a sequence of octets, not a sequence of characters. To convert the cookie-string (or components thereof) into a sequence of characters (e.g., for presentation to the user), the user agent might wish to try using the UTF-8 character encoding [RFC3629] to decode the octet sequence. This decoding might fail, however, because not every sequence of octets is valid UTF-8.

6. 実装上の考慮点

6.1. 制限

実施上、 UA の実装は,格納­可能なクッキーの総数とサイズを制限する。 汎用の UA は、少なくとも次に示す容量は提供するべきである: Practical user agent implementations have limits on the number and size of cookies that they can store. General-use user agents SHOULD provide each of the following minimum capabilities:

  • 1クッキーあたり,少なくとも 4096 バイト(クッキーの名前, 値, 属性 の長さの総和で) At least 4096 bytes per cookie (as measured by the sum of the length of the cookie's name, value, and attributes).

  • 1ドメインあたり,少なくとも 50 個のクッキー At least 50 cookies per domain.

  • 全部で少なくとも 3000 個のクッキー At least 3000 cookies total.

サーバは、なるべく,実装によるこれらの制限に到達しないように, かつ それぞれのリクエストに Cookie ヘッダが内包されることによる,ネットワーク帯域幅を最小限に抑えるために、できるだけ,少数かつ小容量のクッキーを利用するべきである。 Servers SHOULD use as few and as small cookies as possible to avoid reaching these implementation limits and to minimize network bandwidth due to the Cookie header being included in every request.

UA は利用者からの指示によりクッキーを抹消し得るので、サーバは、 UA が Cookie ヘッダ内に1個以上のクッキーを返すことに失敗した際には, “上品に退行する( gracefull degrade )”べきである。 Servers SHOULD gracefully degrade if the user agent fails to return one or more cookies in the Cookie header because the user agent might evict any cookie at any time on orders from the user.

6.2. API

CookieSet-Cookie ヘッダが,このような込み入った構文を利用する理由の一つは、多くのプラットフォーム(サーバと UA のいずれも)が、クッキーに対する文字列ベースの API (アプリケーション プログラミング インタフェース)を提供し,アプリケーション層のプログラマたちに CookieSet-Cookie ヘッダに利用される構文の生成と構文解析を要求するからである。 その結果、多くのプログラマたちから正しく実装されず,相互運用性の問題が生じている。 One reason the Cookie and Set-Cookie headers use such esoteric syntax is that many platforms (both in servers and user agents) provide a string-based application programming interface (API) to cookies, requiring application-layer programmers to generate and parse the syntax used by the Cookie and Set-Cookie headers, which many programmers have done incorrectly, resulting in interoperability problems.

プラットフォームが、クッキーに対する文字列ベースの API を提供する代わりに,より意味論的な API を提供するなら、より使い易いものになるであろう。 特定の API 設計の推奨はこの文書の視野を超えるが、直列化された日付文字列に代えて,抽象 “Date” オブジェクトを導入することには、明らかな利点がある。 Instead of providing string-based APIs to cookies, platforms would be well-served by providing more semantic APIs. It is beyond the scope of this document to recommend specific API designs, but there are clear benefits to accepting an abstract "Date" object instead of a serialized date string.

6.3. IDNA への依存関係と移行

IDNA2008 [RFC5890] は IDNA2003 に [RFC3490] 取って代わる。 しかしながら,2つの仕様には相違点があるため、一方の下に登録されたドメイン名ラベルと,もう一方の下に登録されたそれとの間で、処理に違いが生じ得る(例えば変換)。 IDNA2003 に基づくドメイン名ラベルが残り続ける間,ある程度の移行期間を要する。 UA は、その IDNA の移行を促進するために, IDNA2008 [RFC5890] を実装するべきであり、また, [UTS46] または [RFC5895] を実装してもよい。 IDNA2008 を実装しない UA は, IDNA2003 [RFC3490] を実装しなければならない IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490]. However, there are differences between the two specifications, and thus there can be differences in processing (e.g., converting) domain name labels that have been registered under one from those registered under the other. There will be a transition period of some time during which IDNA2003-based domain name labels will exist in the wild. User agents SHOULD implement IDNA2008 [RFC5890] and MAY implement [UTS46] or [RFC5895] in order to facilitate their IDNA transition. If a user agent does not implement IDNA2008, the user agent MUST implement IDNA2003 [RFC3490].

7. プライバシーに関する考慮点

クッキーは,サーバによる利用者の追跡にも用いられることから、しばしば,批判の対象にされる。 例えば,いくつもの “ウェブ解析” 会社が、利用者がいつウェブサイトに戻って来て,いつ別のウェブサイトを訪問したかを見分ける目的に、クッキーを利用する。 クッキーは,複数の HTTP リクエストに渡って利用者を追跡するためにサーバが利用できる唯一の仕組みではないが、 UA のセッションに渡って永続的であり,かつホスト間で共有し得ることから、追跡を容易にするものではある。 Cookies are often criticized for letting servers track users. For example, a number of "web analytics" companies use cookies to recognize when a user returns to a web site or visits another web site. Although cookies are not the only mechanism servers can use to track users across HTTP requests, cookies facilitate tracking because they are persistent across user agent sessions and can be shared between hosts.

7.1. 第三者主体( third-party )によるクッキー

とりわけ厄介なものは、“第三者主体” クッキーと呼ばれるものである。 HTML 文書の具現化に際し、 UA はしばしば,他のサーバ(広告ネットワークなど)からのリソースをリクエストする。 これらの第三者主体サーバは、利用者がサーバを直接­訪問したことが一度もなくても,利用者の追跡にクッキーを利用できる。 例えば、利用者が第三者主体が供する内容を含んでいるサイトを訪問した後,同じ第三者主体が供する内容を含んでいる別サイトを訪問した場合、その第三者主体は,2つのサイト間で利用者を追跡できる。 Particularly worrisome are so-called "third-party" cookies. In rendering an HTML document, a user agent often requests resources from other servers (such as advertising networks). These third-party servers can use cookies to track the user even if the user never visits the server directly. For example, if a user visits a site that contains content from a third party and then later visits another site that contains content from the same third party, the third party can track the user between the two sites.

一部の UA は第三者主体クッキーのふるまいを制約する。 例えば,これらの UA の一部は、第三者主体へ向けたリクエストの中の Cookie ヘッダの送信を拒否する。 他のものは、第三者主体へのリクエストに対する応答の中の Set-Cookie ヘッダの処理を拒否する。 UA による,それらの第三者主体クッキー­ポリシーは、広範に渡る。 この文書は、利用者のプライバシーと互換性の必要とのバランスをとるための, UA による第三者主体クッキー­ポリシーにおける試みに対し,寛容さをもって許容するが、特定のいかなる第三者主体クッキー­ポリシーも,支持するものではない。 Some user agents restrict how third-party cookies behave. For example, some of these user agents refuse to send the Cookie header in third-party requests. Others refuse to process the Set-Cookie header in responses to third-party requests. User agents vary widely in their third-party cookie policies. This document grants user agents wide latitude to experiment with third-party cookie policies that balance the privacy and compatibility needs of their users. However, this document does not endorse any particular third-party cookie policy.

第三者主体クッキーの遮断ポリシーは、利用者の追跡にかけられた制約をサーバがすり抜ける試みに対しては,しばしば,そのプライバシー目的の面で無力である。 特に,2つの協調するサーバは、識別情報を動的 URL に挿入することにより,クッキーを全く利用せずに利用者を追跡できる。 Third-party cookie blocking policies are often ineffective at achieving their privacy goals if servers attempt to work around their restrictions to track users. In particular, two collaborating servers can often track users without using cookies at all by injecting identifying information into dynamic URLs.

7.2. 利用者による制御

UA は、クッキー保管庫に格納されているクッキーを管理するための仕組みを,利用者に提供するべきである。 例えば、指定された期間内に受信されたものや, 特定のドメインに関連するような,すべてのクッキーを、利用者が削除できるようにするなど。 多くの UA には、利用者がクッキー保管庫に格納されているクッキーを検分できるような,利用者インタフェースが組み込まれている。 User agents SHOULD provide users with a mechanism for managing the cookies stored in the cookie store. For example, a user agent might let users delete all cookies received during a specified time period or all the cookies related to a particular domain. In addition, many user agents include a user interface element that lets users examine the cookies stored in their cookie store.

UA は、クッキーを無効化する仕組みを,利用者に提供するべきである。 クッキーが無効化されている場合、 UA は outbound†(サーバ向け) HTTP リクエストに Cookie ヘッダを内包してはならず,また inbound† HTTP 応答の Set-Cookie ヘッダを処理してはならない User agents SHOULD provide users with a mechanism for disabling cookies. When cookies are disabled, the user agent MUST NOT include a Cookie header in outbound HTTP requests and the user agent MUST NOT process Set-Cookie headers in inbound HTTP responses.

【† HTTP 仕様( RFC2616 )と,語の用法が正反対( UA 視点)になっている。 】

一部の UA は、複数セッションにわたるクッキーの永続的な保管を防止するオプションを,利用者に提供する。 そのように設定された場合、 UA は,受信されたすべてのクッキーを, persistent-flagfalse にされたかのように,扱わなければならない。 一部の普及している UA は、この機能を “プライベートブラウジング” モードとして公開している [Aggarwal2010] Some user agents provide users the option of preventing persistent storage of cookies across sessions. When configured thusly, user agents MUST treat all received cookies as if the persistent-flag were set to false. Some popular user agents expose this functionality via "private browsing" mode [Aggarwal2010].

一部の UA は、クッキー保管庫への個々の書き込みについて,その是非を設定する機能を、利用者に提供する。 多くの一般的な利用局面において、これらの制御は,多数の入力指示を生成する。 それでもなお、プライバシー意識の高い一部の利用者は,これらの制御に有用さを見いだす。 Some user agents provide users with the ability to approve individual writes to the cookie store. In many common usage scenarios, these controls generate a large number of prompts. However, some privacy-conscious users find these controls useful nonetheless.

7.3. 有効期限

サーバは,クッキーの有効期限を遠い未来に設定できるが、ほとんどの UA は,実際にクッキーを何十年も保持することはない。 サーバは、不必要に長い有効期間を設定せずに,クッキーの目的に基づく,理に適った有効期間にすることにより、利用者プライバシーを向上させるべきである。 例えば、典型的なセッション識別子の期限は,2週間 程度が妥当であろう。 Although servers can set the expiration date for cookies to the distant future, most user agents do not actually retain cookies for multiple decades. Rather than choosing gratuitously long expiration periods, servers SHOULD promote user privacy by selecting reasonable cookie expiration periods based on the purpose of the cookie. For example, a typical session identifier might reasonably be set to expire in two weeks.

8. セキュリティ上の考慮点

8.1. 概観

クッキーには、いくつかのセキュリティ上の落とし穴がある。 この節では、その中で少数の,特に主要な問題を概観する。 Cookies have a number of security pitfalls. This section overviews a few of the more salient issues.

クッキーは特に、開発者の,認証における ambient 権限 への依存度を高め、しばしば、サイトをまたがるリクエストの偽造( Cross-Site Request Forgery )のような攻撃に対する脆弱性に転じる [CSRF] 。 また、セッション識別子をクッキーに格納する際に,開発者はしばしば,セッション固定化( session fixation 参考)の脆弱性を生み出す。 In particular, cookies encourage developers to rely on ambient authority for authentication, often becoming vulnerable to attacks such as cross-site request forgery [CSRF]. Also, when storing session identifiers in cookies, developers often create session fixation vulnerabilities.

クッキー­プロトコルには,それ自体に種々の脆弱性があるので(下の 機密性の弱点, 完全性の弱点 を見よ)、 HTTPS にて使役されるようなトランスポート層の暗号化は,ネットワーク攻撃者による被害者のクッキー取得/変更の防止には不足である。 加えて,既定の条件下では、クッキーは,たとえ HTTPS と併用されていたとしても,ネットワーク攻撃者からの機密性や完全性の保護を提供しない。 Transport-layer encryption, such as that employed in HTTPS, is insufficient to prevent a network attacker from obtaining or altering a victim's cookies because the cookie protocol itself has various vulnerabilities (see "Weak Confidentiality" and "Weak Integrity", below). In addition, by default, cookies do not provide confidentiality or integrity from network attackers, even when used in conjunction with HTTPS.

8.2. Ambient 権限

利用者の認証にクッキーを利用するサーバは、一部の UA が,リモート主体による UA からの(例えば, HTTP リダイレクトや HTML フォームを通した) HTTP リクエストの発行を放置するので、セキュリティ脆弱性に悩まされることになる。 そのような UA は、それらのリクエストの発行に際し,リモート主体がそのクッキーの内容について未知であっても、クッキーを添付してしまう。 その結果、騙され易いサーバは,リモート主体から権限を行使され得ることになる。 A server that uses cookies to authenticate users can suffer security vulnerabilities because some user agents let remote parties issue HTTP requests from the user agent (e.g., via HTTP redirects or HTML forms). When issuing those requests, user agents attach cookies even if the remote party does not know the contents of the cookies, potentially letting the remote party exercise authority at an unwary server.

このセキュリティの懸念には,いくつかの呼称があるが(例えば、 “クロスサイト リクエストフォージェリ”【*1】 や “混乱した使節の問題”【*2】 )、問題は,クッキーが ambient 権限 【*3】 の一形態である所から端を発する。 クッキーは、( URL の形をとる)対象の指定( designation )と(クッキーの形をとる)対象への権限付与( authorization )との分離を,サーバの運用者たちに促してしまう。 その結果、 UA は,攻撃者が指定するリソースに権限を与えてしまい、サーバやクライアントは、攻撃者により指定された行為を,彼らが利用者から権限を与えられたかのように,引き受けてしまう可能性がある。 Although this security concern goes by a number of names (e.g., cross-site request forgery, confused deputy), the issue stems from cookies being a form of ambient authority. Cookies encourage server operators to separate designation (in the form of URLs) from authorization (in the form of cookies). Consequently, the user agent might supply the authorization for a resource designated by the attacker, possibly causing the server or its clients to undertake actions designated by the attacker as though they were authorized by the user.

サーバの運用者たちが、クッキーを権限付与に用いる代わりに, URL を capabilities 【*4】 として扱うことにより、対象の指定と対象への権限付与を結合させることも考えられる。 このアプローチは、秘匿情報をクッキーに格納する代わりに URL に格納して,リモートの主体が秘匿情報­自体を供することを要求する。 このアプローチは万能ではないが、この原理を思慮深く応用すれば,より堅牢なセキュリティを導入し得る。 Instead of using cookies for authorization, server operators might wish to consider entangling designation and authorization by treating URLs as capabilities. Instead of storing secrets in cookies, this approach stores secrets in URLs, requiring the remote entity to supply the secret itself. Although this approach is not a panacea, judicious application of these principles can lead to more robust security.

8.3. 平文テキスト

( TLS などの)セキュア­チャンネルを通して送信されるのでない限り、 CookieSet-Cookie ヘッダ内の情報は,平文のまま伝送される。 Unless sent over a secure channel (such as TLS), the information in the Cookie and Set-Cookie headers is transmitted in the clear.

  1. これらのヘッダにより運ばれる,セキュリティに敏感な情報すべてが、盗聴者に公開される。 All sensitive information conveyed in these headers is exposed to an eavesdropper.

  2. 悪意のある中継点は,いずれの方向へ流れるヘッダにも細工を加え得るため、結果は予測できない。 A malicious intermediary could alter the headers as they travel in either direction, with unpredictable results.

  3. 悪意のあるクライアントは、 Cookie ヘッダに,その伝送前に細工を加え得るため、結果は予測できない。 A malicious client could alter the Cookie header before transmission, with unpredictable results.

サーバは、クッキーの内容を UA に伝送する際に(クッキーをセキュア­チャンネルを通して送信するときでも)、(サーバが望む何らかの形式で)暗号化と署名を施すべきである。 しかしながら,クッキーの内容に対する暗号化と署名は、攻撃者による, UA から別の UA へのクッキーの植え付け( transplanting ), あるいは 後の時点におけるクッキーの再現を、防止するものではない。 Servers SHOULD encrypt and sign the contents of cookies (using whatever format the server desires) when transmitting them to the user agent (even when sending the cookies over a secure channel). However, encrypting and signing cookie contents does not prevent an attacker from transplanting a cookie from one user agent to another or from replaying the cookie at a later time.

高レベルのセキュリティを要するサーバは、それぞれのクッキーの内容に対する暗号化と署名に加えて,セキュア­チャンネルを通してのみ CookieSet-Cookie ヘッダを用いるべきである。 セキュア­チャンネルを通してクッキーを利用する際は、サーバはどのクッキーにも Secure 属性( 4.1.2.5 節 )を設定するべきである。 サーバが Secure 属性を設定しない場合、セキュア­チャンネルにより提供される保護は,ほぼ無意味と化すことになる。 In addition to encrypting and signing the contents of every cookie, servers that require a higher level of security SHOULD use the Cookie and Set-Cookie headers only over a secure channel. When using cookies over a secure channel, servers SHOULD set the Secure attribute (see Section 4.1.2.5) for every cookie. If a server does not set the Secure attribute, the protection provided by the secure channel will be largely moot.

例えば、クッキーの中にセッション識別子を格納するウェブメール­サーバがあって,通常は HTTPS を通してアクセスされるとする。 サーバがそのクッキーに Secure 属性を設定しなかった場合、ネットワーク攻撃者は、 UA からの任意の outbound HTTP リクエストを傍受して,ウェブメール­サーバに向けて,そのリクエストを HTTP を通してリダイレクトさせることが可能になる。 ウェブメール­サーバが HTTP 接続をリッスンしていなくても、依然として, UA は 【リダイレクトにおける】 リクエストの中にクッキーを内包させることになる。 ネットワーク攻撃者は、これらのクッキーを傍受して,サーバに向けてそれらを再現することにより、利用者のメール内容を読み取ることが可能になる。 サーバが Secure 属性をそのクッキーに設定していたなら、 UA はそのクッキーを平文テキストのリクエストの中に内包させはしないであろう。 For example, consider a webmail server that stores a session identifier in a cookie and is typically accessed over HTTPS. If the server does not set the Secure attribute on its cookies, an active network attacker can intercept any outbound HTTP request from the user agent and redirect that request to the webmail server over HTTP. Even if the webmail server is not listening for HTTP connections, the user agent will still include cookies in the request. The active network attacker can intercept these cookies, replay them against the server, and learn the contents of the user's email. If, instead, the server had set the Secure attribute on its cookies, the user agent would not have included the cookies in the clear-text request.

8.4. セッション識別子

サーバが、セッション情報を直接的に(攻撃者に公開されたり, 再現され得る)クッキーに格納させる代わりに, nonce (ナンス — “number used once”, 別名“セッション識別子”)をクッキーに格納させることが、広く行われている。 サーバは、 nonce を伴う HTTP リクエストを受信したとき,その nonce をキーに,そのクッキーに結び付けられている状態­情報を検索できる。 Instead of storing session information directly in a cookie (where it might be exposed to or replayed by an attacker), servers commonly store a nonce (or "session identifier") in a cookie. When the server receives an HTTP request with a nonce, the server can look up state information associated with the cookie using the nonce as a key.

nonce は,(それ自身がセキュリティに敏感である非 nonce のクッキーの内容と異なり)サーバとのやりとりにおいてのみ有用なので、セッション識別子クッキーの利用下では,攻撃者にクッキーの内容を読み取られたときの被害が制限される。 更に,使い捨て nonce を利用することで、攻撃者が,サーバとの2回のやりとりからクッキーの内容を “継ぎ接ぎ” して,サーバのふるまいを予期しないものにすることは、防止される。 Using session identifier cookies limits the damage an attacker can cause if the attacker learns the contents of a cookie because the nonce is useful only for interacting with the server (unlike non-nonce cookie content, which might itself be sensitive). Furthermore, using a single nonce prevents an attacker from "splicing" together cookie content from two interactions with the server, which could cause the server to behave unexpectedly.

セッション識別子の利用にはリスクが伴う。 例えば、サーバは, “セッション固定化(セッション強制)” の脆弱性を避けるべく,注意を払うべきである。 セッション固定化の攻撃は3つの段階を経て行われる。 最初の段階では、攻撃者は,セッション識別子を自身の UA で取得してから,被害者の UA に植え付ける。 次の段階では、被害者がそのセッション識別子をサーバとのやりとりに利用する(セッション識別子には,利用者の資格証明( credentials )や機密( confidential )に関する情報も伴われている可能性がある)。 最後の段階では、攻撃者がサーバとの直接のやりとりにそのセッション識別子を利用する(利用者の権限( authority )や機密に関する情報が奪われる可能性がある)。 Using session identifiers is not without risk. For example, the server SHOULD take care to avoid "session fixation" vulnerabilities. A session fixation attack proceeds in three steps. First, the attacker transplants a session identifier from his or her user agent to the victim's user agent. Second, the victim uses that session identifier to interact with the server, possibly imbuing the session identifier with the user's credentials or confidential information. Third, the attacker uses the session identifier to interact with server directly, possibly obtaining the user's authority or confidential information.

【 植え付ける — transplant : (訳者独自の解釈)何らかの方法(具体的な方法は多岐にわたる)で、被害者を「攻撃者がセッション識別子により,一定の権限を持った状態でサーバにアクセスできる状況」と同一の状況に誘導する(しかる後,“体を入れ替える” — 攻撃者が用意した “合鍵” を被害者に利用させ、しかる後,同じ鍵で侵入する — 従って、 “ログイン” 時に鍵を交換することが有効な対策になると考えられる)。】

8.5. 機密性の弱点

クッキーはポートによる隔離を提供しない。 クッキーが,あるポート上で動作するサービスで読み取り可能であるならば、そのクッキーは,同じサーバの別ポート上のサービスでも読み取り可能になる。 クッキーが,あるポート上のサービスで書き込み可能であるならば、そのクッキーは,同じサーバの別ポート上のサービスでも書き込み可能になる。 この理由から、サーバは、同じホストの異なるポート上で,互いの信頼関係のないサービスを同時に実行しているときは、セキュリティに敏感な情報の格納にクッキーを利用するべきでない。 Cookies do not provide isolation by port. If a cookie is readable by a service running on one port, the cookie is also readable by a service running on another port of the same server. If a cookie is writable by a service on one port, the cookie is also writable by a service running on another port of the same server. For this reason, servers SHOULD NOT both run mutually distrusting services on different ports of the same host and use cookies to store security-sensitive information.

クッキーはスキームによる隔離を提供しない。 クッキーは http と https スキームで最も広く利用されるが、与えられたホストに対するクッキーは, ftp や gopher などの他のスキームでも可用になり得る。 この,スキームによる隔離の欠如は、クッキーへのアクセスを許可する “非 HTTP” API (例えば HTML の document.cookie API )において顕著に見られるが、スキームによる隔離の欠如はまた,クッキーの処理要件自体にも実際に存在する(例えば、 HTTP を通した, gopher スキーム URI からの取得を考えてみよ)。 Cookies do not provide isolation by scheme. Although most commonly used with the http and https schemes, the cookies for a given host might also be available to other schemes, such as ftp and gopher. Although this lack of isolation by scheme is most apparent in non-HTTP APIs that permit access to cookies (e.g., HTML's document.cookie API), the lack of isolation by scheme is actually present in requirements for processing cookies themselves (e.g., consider retrieving a URI with the gopher scheme via HTTP).

クッキーはパスによる隔離を常に提供するものではない。 ネットワーク­レベルのプロトコルでは、あるパスに対応して格納されたクッキーが,別のパスに向けて送信されることはないが、一部の UA は, HTML の document.cookie API などの “非 HTTP” API を通して,クッキーを公開する。 これらの UA の一部(例えば,ウェブブラウザなど)は,異なるパスから受信されたリソースを隔離しないので、あるパスから得られたリソースから,別のパスに対応して格納されたクッキーにアクセスし得る。 Cookies do not always provide isolation by path. Although the network-level protocol does not send cookies stored for one path to another, some user agents expose cookies via non-HTTP APIs, such as HTML's document.cookie API. Because some of these user agents (e.g., web browsers) do not isolate resources received from different paths, a resource retrieved from one path might be able to access cookies stored for another path.

8.6. 完全性の弱点

クッキーは、隣接ドメイン(およびそれらの下位ドメイン)に対する完全性( integrity )を保証しない。 例えば, foo.example.combar.example.com を考える。 foo.example.com のサーバは、 Domain 属性 "example.com" のクッキーを設定できる(したがって,既存の "example.com" クッキーを上書きするかもしれない)。 UA は、そのクッキーを bar.example.com へ向けた HTTP リクエストに内包することになる。 最悪の場合、 bar.example.com は,このクッキーと自身が設定したクッキーとを判別できなくなる。 foo.example.com サーバは、 bar.example.com に対する攻撃にこの能力を利用し得る。 Cookies do not provide integrity guarantees for sibling domains (and their subdomains). For example, consider foo.example.com and bar.example.com. The foo.example.com server can set a cookie with a Domain attribute of "example.com" (possibly overwriting an existing "example.com" cookie set by bar.example.com), and the user agent will include that cookie in HTTP requests to bar.example.com. In the worst case, bar.example.com will be unable to distinguish this cookie from a cookie it set itself. The foo.example.com server might be able to leverage this ability to mount an attack against bar.example.com.

Set-Cookie ヘッダが Path 属性をサポートしていても, UA は Set-Cookie ヘッダ内の任意の Path 属性を受理するので、 Path 属性は,いかなる完全性の保護も提供しない。 例えば, http://example.com/foo/bar に向けたリクエストに対する HTTP 応答は、 Path 属性 "/qux" のクッキーを設定できる。 したがってサーバは、同じホストの異なるパス上で,互いの信頼関係のないサービスを同時に実行しているときは、セキュリティに敏感な情報の格納にクッキーを利用するべきでない。 Even though the Set-Cookie header supports the Path attribute, the Path attribute does not provide any integrity protection because the user agent will accept an arbitrary Path attribute in a Set-Cookie header. For example, an HTTP response to a request for http://example.com/foo/bar can set a cookie with a Path attribute of "/qux". Consequently, servers SHOULD NOT both run mutually distrusting services on different paths of the same host and use cookies to store security-sensitive information.

ネットワーク攻撃者は、 http://example.com/ からの応答を模倣して Set-Cookie ヘッダを挿入することにより, https://example.com/ に向けて送信される Cookie ヘッダにクッキーを挿入できる。 example.com にある HTTPS サーバは、 HTTPS 応答の中のこれらのクッキーと自身が設定したクッキーとを,判別できない。 example.com が HTTPS を排他的に利用していたとしても、ネットワーク攻撃者は, example.com に対する攻撃にこの能力を利用し得る。 An active network attacker can also inject cookies into the Cookie header sent to https://example.com/ by impersonating a response from http://example.com/ and injecting a Set-Cookie header. The HTTPS server at example.com will be unable to distinguish these cookies from cookies that it set itself in an HTTPS response. An active network attacker might be able to leverage this ability to mount an attack against example.com even if example.com uses HTTPS exclusively.

サーバは、それらのクッキーの内容に暗号化と署名を施すことにより,これらの攻撃を部分的に軽減できる。 しかしながら、攻撃者は、自身が真正の example.com サーバから受信したクッキーを,利用者のセッションの中で再現できるので、暗号の利用はこの問題を根本から払拭するものではなく,結果は予測できない。 Servers can partially mitigate these attacks by encrypting and signing the contents of their cookies. However, using cryptography does not mitigate the issue completely because an attacker can replay a cookie he or she received from the authentic example.com server in the user's session, with unpredictable results.

最後に、攻撃者は、多数のクッキーを格納させることにより,クッキーの削除を UA に強制し得る。 UA は,その容量制限に到達したとき、何らかのクッキーの抹消を強制されることになる。 サーバは、 UA によるクッキーの保持に依存するべきでない。 Finally, an attacker might be able to force the user agent to delete cookies by storing a large number of cookies. Once the user agent reaches its storage limit, the user agent will be forced to evict some cookies. Servers SHOULD NOT rely upon user agents retaining cookies.

8.7. DNS への依存

クッキーのセキュリティは, DNS ( Domain Name System )に依存する。 DNS が部分的または全部的に弱体化された場合、クッキー プロトコルは,アプリケーションが要するセキュリティの提供に失敗するであろう。 Cookies rely upon the Domain Name System (DNS) for security. If the DNS is partially or fully compromised, the cookie protocol might fail to provide the security properties required by applications.

9. IANA Considerations

恒久的メッセージ ヘッダ レジストリ( [RFC3864] 参照) は以下の登録により更新された。 The permanent message header field registry (see [RFC3864]) has been updated with the following registrations.

9.1. Cookie

ヘッダ名 Cookie
適用可能なプロトコル http
位置付け standard
作成/変更管理 IETF
仕様­文書 この仕様(5.4 節

9.2. Set-Cookie

ヘッダ名 Set-Cookie
適用可能なプロトコル http
位置付け standard
作成/変更管理 IETF
仕様­文書 この仕様(5.2 節

9.3. Cookie2

ヘッダ名 Cookie2
適用可能なプロトコル http
位置付け obsoleted
作成/変更管理 IETF
仕様­文書 [RFC2965]

9.4. Set-Cookie2

ヘッダ名 Set-Cookie2
適用可能なプロトコル http
位置付け obsoleted
作成/変更管理 IETF
仕様­文書 [RFC2965]

10. 参照文献

10.1. 文献(規範的)

[RFC1034]
Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1123]
Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616]
Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3490]
Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. See Section 6.3 for an explanation why the normative reference to an obsoleted specification is needed.
[RFC4790]
Newman, C., Duerst, M., and A. Gulbrandsen, "Internet Application Protocol Collation Registry", RFC 4790, March 2007.
[RFC5234]
Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5890]
Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[USASCII]
American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.

10.2. 文献(参考)

[RFC2109]
Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2109, February 1997.
[RFC2965]
Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2965, October 2000.
[RFC2818]
Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[Netscape]
Netscape Communications Corp., "Persistent Client State -- HTTP Cookies", 1999, <http://web.archive.org/web/20020803110822/http://wp.netscape.com/newsref/std/cookie_spec.html>.
curl サイトにて提供されている複製
[Kri2001]
Kristol, D., "HTTP Cookies: Standards, Privacy, and Politics", ACM Transactions on Internet Technology Vol. 1, #2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>.
[RFC3629]
Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC4648]
Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC3864]
Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC5895]
Resnick, P. and P. Hoffman, "Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008", RFC 5895, September 2010.
[UTS46]
Davis, M. and M. Suignard, "Unicode IDNA Compatibility Processing", Unicode Technical Standards # 46, 2010, <http://unicode.org/reports/tr46/>.
[CSRF]
Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses for Cross-Site Request Forgery", 2008, <http://portal.acm.org/citation.cfm?id=1455770.1455782>.
[Aggarwal2010]
Aggarwal, G., Burzstein, E., Jackson, C., and D. Boneh, "An Analysis of Private Browsing Modes in Modern Browsers", 2010, <http://www.usenix.org/events/sec10/tech/full_papers/Aggarwal.pdf>.

Appendix A. 謝辞

この文書は RFC 2109 [RFC2109] から多くの部分を借りている。 David M. Kristol 氏と Lou Montulli 氏,彼らの cookies 仕様にかけた努力に感謝する。 特に David M. Kristol 氏による, IETF プロセスの進行に関する貴重なアドバイスに。 また、次の方々からの,この文書への有益なフィードバックに感謝する: This document borrows heavily from RFC 2109 [RFC2109]. We are indebted to David M. Kristol and Lou Montulli for their efforts to specify cookies. David M. Kristol, in particular, provided invaluable advice on navigating the IETF process. We would also like to thank

Thomas Broyer, Tyler Close, Alissa Cooper, Bil Corry, corvid, Lisa Dusseault, Roy T. Fielding, Blake Frantz, Anne van Kesteren, Eran Hammer-Lahav, Jeff Hodges, Bjoern Hoehrmann, Achim Hoffmann, Georg Koppen, Dean McNamee, Alexey Melnikov, Mark Miller, Mark Pauley, Yngve N. Pettersen, Julian Reschke, Peter Saint-Andre, Mark Seaborn, Maciej Stachowiak, Daniel Stenberg, Tatsuhiro Tsujikawa, David Wagner, Dan Winship, and Dan Witte for their valuable feedback on this document.