RFC2109 日本語訳
2109 HTTP State Management Mechanism. D. Kristol, L. Montulli. February 1997. (Format: TXT=43469 bytes) (Obsoleted by RFC2965) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Kristol
Request for Comments: 2109 Bell Laboratories, Lucent Technologies
Category: Standards Track L. Montulli
Netscape Communications
February 1997
コメントを求めるワーキンググループD.クリストル要求をネットワークでつないでください: 2109年のベル研究所、ルーセントテクノロジーズカテゴリ: 標準化過程L.Montulliネットスケープ・コミュニケーションズ1997年2月
HTTP State Management Mechanism
HTTP国家管理メカニズム
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
1. ABSTRACT
1. 要約
This document specifies a way to create a stateful session with HTTP requests and responses. It describes two new headers, Cookie and Set-Cookie, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal, but it can interoperate with HTTP/1.0 user agents that use Netscape's method. (See the HISTORICAL section.)
このドキュメントはHTTP要求と応答とのstatefulセッションを作成する方法を指定します。 それは参加することの間まで州の情報を運ぶ2個の新しいヘッダー、Cookie、およびSet-クッキー発生源サーバとユーザエージェントについて説明します。 ここで説明されたメソッドはNetscapeのCookie提案と異なっていますが、それはNetscapeのメソッドを使用するHTTP/1.0人のユーザエージェントと共に共同利用できます。 (HISTORICAL部を見てください。)
2. TERMINOLOGY
2. 用語
The terms user agent, client, server, proxy, and origin server have the same meaning as in the HTTP/1.0 specification.
用語ユーザエージェント、クライアント、サーバ、プロキシ、および発生源サーバには、同じくらいが、HTTP/1.0仕様のように意味しながら、あります。
Fully-qualified host name (FQHN) means either the fully-qualified domain name (FQDN) of a host (i.e., a completely specified domain name ending in a top-level domain such as .com or .uk), or the numeric Internet Protocol (IP) address of a host. The fully qualified domain name is preferred; use of numeric IP addresses is strongly discouraged.
完全に適切なホスト名(FQHN)はホスト(すなわち、.comか.ukなどの最上位のドメインにおける完全に指定されたドメイン名結末)の完全修飾ドメイン名(FQDN)かホストの数値インターネットプロトコル(IP)アドレスのどちらかを意味します。 完全修飾ドメイン名は好まれます。 数値IPアドレスの使用は強くお勧めできないです。
The terms request-host and request-URI refer to the values the client would send to the server as, respectively, the host (but not port) and abs_path portions of the absoluteURI (http_URL) of the HTTP request line. Note that request-host must be a FQHN.
用語要求ホストと要求URIはHTTPのabsoluteURI(http_URL)の一部が要求するホスト(しかし、ポートでない)と腹筋_経路がそれぞれ立ち並ぶときクライアントがサーバに送る値について言及します。 要求ホストがFQHNであるに違いないことに注意してください。
Kristol & Montulli Standards Track [Page 1] RFC 2109 HTTP State Management Mechanism February 1997
クリストルとMontulli規格はHTTP国家管理メカニズム1997年2月にRFC2109を追跡します[1ページ]。
Hosts names can be specified either as an IP address or a FQHN string. Sometimes we compare one host name with another. Host A's name domain-matches host B's if
IPアドレスとして指定されていて、名前がそうすることができるか、またはFQHNが結ぶホスト。 時々、私たちは別のものと1つのホスト名を比べます。 ホストAの名前ドメインマッチはビーズを接待します。
* both host names are IP addresses and their host name strings match
exactly; or
* 両方のホスト名はIPアドレスです、そして、それらのホスト名ストリングはまさに合っています。 または
* both host names are FQDN strings and their host name strings match
exactly; or
* 両方のホスト名はFQDNストリングです、そして、それらのホスト名ストリングはまさに合っています。 または
* A is a FQDN string and has the form NB, where N is a non-empty name
string, B has the form .B', and B' is a FQDN string. (So, x.y.com
domain-matches .y.com but not y.com.)
* 'Aは、FQDNストリングであり、Nが非空の名前ストリングである、Bがフォーム.Bを持っているフォームネブラスカを持っ'て、B'はFQDNストリングです。 (したがって、x.y.comはy.comではなく、.y. comにドメインで合っています。)
Note that domain-match is not a commutative operation: a.b.c.com domain-matches .c.com, but not the reverse.
ドメインマッチが可換的演算でないことに注意してください: a. b. c. 逆ではなく、comドメインマッチ.c. com。
Because it was used in Netscape's original implementation of state management, we will use the term cookie to refer to the state information that passes between an origin server and user agent, and that gets stored by the user agent.
それがNetscapeの国家管理のオリジナルの実装に使用されたので、私たちは発生源サーバとユーザエージェントの間を通って、ユーザエージェントによって保存される州の情報を示すのにクッキーという用語を使用するつもりです。
3. STATE AND SESSIONS
3. 状態とセッション
This document describes a way to create stateful sessions with HTTP requests and responses. Currently, HTTP servers respond to each client request without relating that request to previous or subsequent requests; the technique allows clients and servers that wish to exchange state information to place HTTP requests and responses within a larger context, which we term a "session". This context might be used to create, for example, a "shopping cart", in which user selections can be aggregated before purchase, or a magazine browsing system, in which a user's previous reading affects which offerings are presented.
このドキュメントはHTTP要求と応答とのstatefulセッションを作成する方法を述べます。 現在、前の、または、その後の要求にその要求に関連しないで、HTTPサーバはそれぞれのクライアント要求に応じます。 州の情報を交換したがっているクライアントとサーバが、より大きい文脈の中にテクニックでHTTP要求と応答を置くことができる、どれ、私たち、「セッション」という用語。 この文脈は、例えば、購買の前にユーザ選択を集めることができる「ショッピングカート」、または雑誌ブラウジングシステムを作成するのに使用されるかもしれません。(そこでは、ユーザの前の読書が、どの提供が寄贈されるかに影響します)。
There are, of course, many different potential contexts and thus many different potential types of session. The designers' paradigm for sessions created by the exchange of cookies has these key attributes:
もちろん、セッションの多くの異なった潜在的関係とその結果多くの異なった潜在的タイプがあります。 クッキーの交換で作成されたセッションのためのデザイナーのパラダイムには、これらの主要な属性があります:
1. Each session has a beginning and an end.
1. 各セッションには、起源と端があります。
2. Each session is relatively short-lived.
2. それぞれのセッションは比較的短命です。
3. Either the user agent or the origin server may terminate a
session.
3. ユーザエージェントか発生源サーバのどちらかがセッションを終えるかもしれません。
4. The session is implicit in the exchange of state information.
4. セッションは州の情報の交換で暗黙です。
Kristol & Montulli Standards Track [Page 2] RFC 2109 HTTP State Management Mechanism February 1997
クリストルとMontulli規格はHTTP国家管理メカニズム1997年2月にRFC2109を追跡します[2ページ]。
4. OUTLINE
4. アウトライン
We outline here a way for an origin server to send state information to the user agent, and for the user agent to return the state information to the origin server. The goal is to have a minimal impact on HTTP and user agents. Only origin servers that need to maintain sessions would suffer any significant impact, and that impact can largely be confined to Common Gateway Interface (CGI) programs, unless the server provides more sophisticated state management support. (See Implementation Considerations, below.)
私たちはここに発生源サーバが州の情報をユーザエージェントに送って、ユーザエージェントが州の情報を発生源サーバに返す方法を概説します。目標はHTTPとユーザエージェントの上に最小量の影響力を持つことです。 セッションを維持する必要がある発生源サーバだけがどんな重要な影響も受けるでしょう、そして、共通ゲートウェイインターフェイス(CGI)プログラムにその影響は主に閉じ込めることができます、サーバが、より洗練された国家管理サポートを提供しない場合。 (以下のImplementation Considerationsを見てください。)
4.1 Syntax: General
4.1構文: 一般
The two state management headers, Set-Cookie and Cookie, have common syntactic properties involving attribute-value pairs. The following grammar uses the notation, and tokens DIGIT (decimal digits) and token (informally, a sequence of non-special, non-white space characters) from the HTTP/1.1 specification [RFC 2068] to describe their syntax.
2個の国家管理ヘッダー(Set-クッキーとCookie)が、一般的な構文の特性を属性値組にかかわらせます。 以下の文法が記法、トークンDIGIT(10進数字)、およびトークンを使用する、(非公式である、非特別で、非余白のキャラクタの系列) 彼らの構文について説明するHTTP/1.1仕様[RFC2068]から。
av-pairs = av-pair *(";" av-pair)
av-pair = attr ["=" value] ; optional value
attr = token
value = word
word = token | quoted-string
av-組がav-組*と等しい、(「; 」 av-組) av-組はattr[値と「等しい」]と等しいです。 トークン任意の値のattr=値は単語単語=トークンと等しいです。| 引用文字列
Attributes (names) (attr) are case-insensitive. White space is permitted between tokens. Note that while the above syntax description shows value as optional, most attrs require them.
属性(名前)(attr)は大文字と小文字を区別しないです。 余白はトークンの間で受入れられます。 上の構文記述が任意であるとして値を示している間ほとんどのattrsが彼らを必要とすることに注意してください。
NOTE: The syntax above allows whitespace between the attribute and the = sign.
以下に注意してください。 上の構文は属性と=サインの間の空白を許容します。
4.2 Origin Server Role
4.2 発生源サーバーの役割
4.2.1 General
4.2.1 一般
The origin server initiates a session, if it so desires. (Note that "session" here does not refer to a persistent network connection but to a logical session created from HTTP requests and responses. The presence or absence of a persistent connection should have no effect on the use of cookie-derived sessions). To initiate a session, the origin server returns an extra response header to the client, Set- Cookie. (The details follow later.)
そう望んでいるなら、発生源サーバはセッションを開始します。 (永続的なネットワーク接続が参照されるのではなく、ここの「セッション」がHTTP要求と応答から作成された論理的なセッションまで参照されることに注意してください。 パーシステントコネクションの存在か欠如がクッキーで派生しているセッションの使用のときに効き目があるべきではありません。). セッションを開始するために、発生源サーバはクライアントへの付加的な応答ヘッダ、Setクッキーを返します。 (詳細は後で従います。)
A user agent returns a Cookie request header (see below) to the origin server if it chooses to continue a session. The origin server may ignore it or use it to determine the current state of the
セッションを続けているのを選ぶなら、ユーザエージェントはCookie要求ヘッダー(以下を見る)を発生源サーバに返します。 発生源サーバは、現状を決定するのにそれを無視するか、またはそれを使用するかもしれません。
Kristol & Montulli Standards Track [Page 3] RFC 2109 HTTP State Management Mechanism February 1997
クリストルとMontulli規格はHTTP国家管理メカニズム1997年2月にRFC2109を追跡します[3ページ]。
session. It may send back to the client a Set-Cookie response header with the same or different information, or it may send no Set-Cookie header at all. The origin server effectively ends a session by sending the client a Set-Cookie header with Max-Age=0.
セッション。 それが同じであるか異なった情報でSet-クッキー応答ヘッダをクライアントに送り返すかもしれませんか、またはそれはSet-クッキーヘッダーを全く送らないかもしれません。 事実上、発生源サーバはマックス-時代があるSet-クッキーヘッダーをクライアントに送るのによるセッション=0を終わらせます。
Servers may return a Set-Cookie response headers with any response. User agents should send Cookie request headers, subject to other rules detailed below, with every request.
サーバはどんな応答と共にもSet-クッキーに応答ヘッダを返すかもしれません。 ユーザエージェントはあらゆる要求のときに以下で詳細な他の規則を条件としてCookie要求ヘッダーを送るべきです。
An origin server may include multiple Set-Cookie headers in a response. Note that an intervening gateway could fold multiple such headers into a single header.
発生源サーバは応答に複数のSet-クッキーヘッダーを含むかもしれません。 介入しているゲートウェイが複数のそのようなヘッダーを独身のヘッダーに折り重ねるかもしれないことに注意してください。
4.2.2 Set-Cookie Syntax
4.2.2 セットクッキー構文
The syntax for the Set-Cookie response header is
Set-クッキー応答ヘッダのための構文はそうです。
set-cookie = "Set-Cookie:" cookies
cookies = 1#cookie
cookie = NAME "=" VALUE *(";" cookie-av)
NAME = attr
VALUE = value
cookie-av = "Comment" "=" value
| "Domain" "=" value
| "Max-Age" "=" value
| "Path" "=" value
| "Secure"
| "Version" "=" 1*DIGIT
セットクッキー=、「セットクッキー:」 クッキークッキーが1#クッキークッキー=NAME「=」価値*と等しい、(「」、;値クッキー-av=クッキー-av) 名前=attr価値=「コメント」が値と「等しい」 | 「ドメイン」「=」価値| 「マックス-時代」は値と「等しいです」。| 「経路」「=」価値| 「安全です」。| 「バージョン」は1*ケタと「等しいです」。
Informally, the Set-Cookie response header comprises the token Set- Cookie:, followed by a comma-separated list of one or more cookies. Each cookie begins with a NAME=VALUE pair, followed by zero or more semi-colon-separated attribute-value pairs. The syntax for attribute-value pairs was shown earlier. The specific attributes and the semantics of their values follows. The NAME=VALUE attribute- value pair must come first in each cookie. The others, if present, can occur in any order. If an attribute appears more than once in a cookie, the behavior is undefined.
非公式に、Set-クッキー応答ヘッダはトークンSetを含みます。クッキー: 1個以上のクッキーのコンマで切り離されたリストはあとに続きます。 各クッキーはゼロか準コロンが、より分離している属性値組によってついて来られたNAME=VALUE組と共に始まります。 属性値組構文は、より早く示されました。 特定の属性とそれらの値の意味論は従います。 値の組が最初に各クッキーの中に来させなければならないNAME=VALUE属性。 存在しているなら、他のものは順不同に起こることができます。 属性がクッキーの中に一度より多く見えるなら、振舞いは未定義です。
NAME=VALUE
Required. The name of the state information ("cookie") is NAME,
and its value is VALUE. NAMEs that begin with $ are reserved for
other uses and must not be used by applications.
名前=価値が必要です。 州の情報(「クッキー」)の名前はNAMEです、そして、値はVALUEです。 $で始まるNAMEsを他の用途のために予約して、アプリケーションで使用してはいけません。
Kristol & Montulli Standards Track [Page 4] RFC 2109 HTTP State Management Mechanism February 1997
クリストルとMontulli規格はHTTP国家管理メカニズム1997年2月にRFC2109を追跡します[4ページ]。
The VALUE is opaque to the user agent and may be anything the
origin server chooses to send, possibly in a server-selected
printable ASCII encoding. "Opaque" implies that the content is of
interest and relevance only to the origin server. The content
may, in fact, be readable by anyone that examines the Set-Cookie
header.
VALUEはユーザエージェントにとって不透明であり、ことによるとサーバで選択された印刷可能なASCIIでコード化を送る発生源サーバが、選ぶ何かであるかもしれません。 「不透明なもの」は、内容が発生源サーバだけへの関心と関連性のものであることを含意します。事実上、内容はSet-クッキーヘッダーを調べるだれでも読み込み可能であるかもしれません。
Comment=comment
Optional. Because cookies can contain private information about a
user, the Cookie attribute allows an origin server to document its
intended use of a cookie. The user can inspect the information to
decide whether to initiate or continue a session with this cookie.
コメントはコメントと任意の状態で等しいです。 クッキーがユーザに関する個人情報を含むことができるので、Cookie属性で、発生源サーバはクッキーの意図している使用を記録できます。 ユーザは、このクッキーとのセッションを開始するか、または続けているかを決めるために情報を点検できます。
Domain=domain
Optional. The Domain attribute specifies the domain for which the
cookie is valid. An explicitly specified domain must always start
with a dot.
ドメインはドメインと任意の状態で等しいです。 Domain属性はクッキーが有効であるドメインを指定します。 明らかに指定されたドメインはいつもドットから始まらなければなりません。
Max-Age=delta-seconds
Optional. The Max-Age attribute defines the lifetime of the
cookie, in seconds. The delta-seconds value is a decimal non-
negative integer. After delta-seconds seconds elapse, the client
should discard the cookie. A value of zero means the cookie
should be discarded immediately.
=デルタ秒の任意の状態でマックスと同じくらい年をとってください。 マックス-時代属性は秒にクッキーの生涯を定義します。 デルタ秒値は10進非負の整数です。 デルタ秒秒が経過した後に、クライアントはクッキーを捨てるべきです。 ゼロの値は、クッキーがすぐに捨てられるべきであることを意味します。
Path=path
Optional. The Path attribute specifies the subset of URLs to
which this cookie applies.
経路は経路と任意の状態で等しいです。 Path属性はこのクッキーが適用されるURLの部分集合を指定します。
Secure
Optional. The Secure attribute (with no value) directs the user
agent to use only (unspecified) secure means to contact the origin
server whenever it sends back this cookie.
安全である、任意です。 Secure属性(値のない)は、このクッキーを返送するときはいつも、発生源サーバに連絡する(不特定)の安全な手段だけを使用するようユーザエージェントに指示します。
The user agent (possibly under the user's control) may determine
what level of security it considers appropriate for "secure"
cookies. The Secure attribute should be considered security
advice from the server to the user agent, indicating that it is in
the session's interest to protect the cookie contents.
ユーザエージェント(ことによるとユーザのコントロールの下における)は、それが、「安全な」クッキーに適切であるとどんなレベルのセキュリティが考えるかを決心するかもしれません。 Secure属性はサーバからユーザエージェントまでのセキュリティアドバイスであると考えられるべきです、クッキーコンテンツを保護するためにセッションの利益のためにはそれがあるのを示して。
Version=version
Required. The Version attribute, a decimal integer, identifies to
which version of the state management specification the cookie
conforms. For this specification, Version=1 applies.
バージョン=バージョンが必要です。 バージョン属性(10進整数)は、クッキーが国家管理仕様のどのバージョンに一致しているかを特定します。この仕様に関して、バージョン=1は申し込まれます。
Kristol & Montulli Standards Track [Page 5] RFC 2109 HTTP State Management Mechanism February 1997
クリストルとMontulli規格はHTTP国家管理メカニズム1997年2月にRFC2109を追跡します[5ページ]。
4.2.3 Controlling Caching
4.2.3 キャッシュを制御すること。
An origin server must be cognizant of the effect of possible caching of both the returned resource and the Set-Cookie header. Caching "public" documents is desirable. For example, if the origin server wants to use a public document such as a "front door" page as a sentinel to indicate the beginning of a session for which a Set- Cookie response header must be generated, the page should be stored in caches "pre-expired" so that the origin server will see further requests. "Private documents", for example those that contain information strictly private to a session, should not be cached in shared caches.
発生源サーバは返されたリソースとSet-クッキーヘッダーの両方の可能なキャッシュの効果を認識していなければなりません。 「公共」のドキュメントをキャッシュするのは望ましいです。 例えば、発生源サーバがSetクッキー応答ヘッダを生成しなければならないセッションの始まりを示すのに歩しょうとしての1「正面玄関」ページなどの官庁出版物を使用したいと思うなら、ページは発生源サーバがさらなる要求を見るように「あらかじめ吐き出された」キャッシュで保存されるべきです。 共有されたキャッシュで「個人的なドキュメント」(例えば、厳密にセッションに個人的な情報を含むもの)をキャッシュするべきではありません。
If the cookie is intended for use by a single user, the Set-cookie header should not be cached. A Set-cookie header that is intended to be shared by multiple users may be cached.
シングルユーザーが使用のためにクッキーを意図するなら、Set-クッキーヘッダーをキャッシュするべきではありません。 複数のユーザによって共有されることを意図するSet-クッキーヘッダーはキャッシュされるかもしれません。
The origin server should send the following additional HTTP/1.1 response headers, depending on circumstances:
事情によって、発生源サーバは以下の追加HTTP/1.1人の応答ヘッダを送るべきです:
* To suppress caching of the Set-Cookie header: Cache-control: no-
cache="set-cookie".
* Set-クッキーヘッダーのキャッシュを抑圧するために: キャッシュ制御: いいえ=「セットクッキー」をキャッシュしてください。
and one of the following:
以下の1つ:
* To suppress caching of a private document in shared caches: Cache-
control: private.
* 共有されたキャッシュにおける、個人的なドキュメントのキャッシュを抑圧するために: コントロールをキャッシュしてください: 個人的。
* To allow caching of a document and require that it be validated
before returning it to the client: Cache-control: must-revalidate.
* ドキュメントがキャッシュされるのを許容して、それをクライアントに返す前にそれが有効にされるのが必要であるように: キャッシュ制御: 必須-revalidate。
* To allow caching of a document, but to require that proxy caches
(not user agent caches) validate it before returning it to the
client: Cache-control: proxy-revalidate.
* しかし、ドキュメントがプロキシが(ユーザエージェントキャッシュでない)をキャッシュするのが必要であるようにキャッシュされるのを許容するには、それをクライアントに返す前に、それを有効にしてください: キャッシュ制御: プロキシ-revalidate。
* To allow caching of a document and request that it be validated
before returning it to the client (by "pre-expiring" it):
Cache-control: max-age=0. Not all caches will revalidate the
document in every case.
* ドキュメントがキャッシュされるのを許容して、クライアント(それの「プレ吐き出す」であるのによる)にそれを返す前にそれが有効にされるよう要求するために: キャッシュ制御: 最大時代=0。 すべてのキャッシュがあらゆる場合にドキュメントを再有効にするというわけではないでしょう。
HTTP/1.1 servers must send Expires: old-date (where old-date is a date long in the past) on responses containing Set-Cookie response headers unless they know for certain (by out of band means) that there are no downsteam HTTP/1.0 proxies. HTTP/1.1 servers may send other Cache-Control directives that permit caching by HTTP/1.1 proxies in addition to the Expires: old-date directive; the Cache- Control directive will override the Expires: old-date for HTTP/1.1 proxies.
HTTP/1.1のサーバがExpiresを送らなければなりません: 彼らが確かに知らないならSet-クッキー応答ヘッダを含む応答のときに老人と同じくらいデートしてください(過去に長い間古い期日が日付であるところ)。(バンド手段) それはdownsteam HTTP/1.0プロキシに全く使い果たされませんでした。 HTTP/1.1のサーバがHTTP/1.1のプロキシでExpiresに加えてキャッシュすることを許可する他のCache-コントロール指示を送るかもしれません: 古い期日の指示。 Cacheコントロール指示はExpiresをくつがえすでしょう: HTTP/1.1のプロキシの古い期日です。
Kristol & Montulli Standards Track [Page 6] RFC 2109 HTTP State Management Mechanism February 1997
クリストルとMontulli規格はHTTP国家管理メカニズム1997年2月にRFC2109を追跡します[6ページ]。
4.3 User Agent Role
4.3 ユーザエージェントの役割
4.3.1 Interpreting Set-Cookie
4.3.1 セットクッキーを解釈すること。
The user agent keeps separate track of state information that arrives via Set-Cookie response headers from each origin server (as distinguished by name or IP address and port). The user agent applies these defaults for optional attributes that are missing:
ユーザエージェントはそれぞれの発生源サーバからのSet-クッキー応答ヘッダを通して到着する州の情報の別々の道を保ちます(名前かIPアドレスとポートによって区別されるように)。 ユーザエージェントはなくなった任意の属性のためにこれらのデフォルトを適用します:
VersionDefaults to "old cookie" behavior as originally specified by
Netscape. See the HISTORICAL section.
「古いクッキー」の振舞いへのVersionDefaultsは同じくらい元々、Netscapeで指定しました。 HISTORICAL部を見てください。
Domain Defaults to the request-host. (Note that there is no dot at
the beginning of request-host.)
要求ホストへのドメインDefaults。 (ドットが全く要求ホストの始めにないことに注意してください。)
Max-AgeThe default behavior is to discard the cookie when the user
agent exits.
マックス-AgeTheデフォルトの振舞いはユーザエージェントが出るとき、クッキーを捨てることです。
Path Defaults to the path of the request URL that generated the
Set-Cookie response, up to, but not including, the
right-most /.
包含、最も権利/ではなく、Set-クッキー応答を生成した要求URLの経路への経路Defaults。
Secure If absent, the user agent may send the cookie over an
insecure channel.
休んだ状態でIfを固定してください、そして、ユーザエージェントは不安定なチャンネルの上にクッキーを送ってもよいです。
4.3.2 Rejecting Cookies
4.3.2 クッキーを拒絶すること。
To prevent possible security or privacy violations, a user agent rejects a cookie (shall not store its information) if any of the following is true:
可能なセキュリティかプライバシー違反を防ぐために、以下のどれかが本当であるなら、ユーザエージェントはクッキー(情報を保存しない)を拒絶します:
* The value for the Path attribute is not a prefix of the request-
URI.
* Path属性のための値は要求URIの接頭語ではありません。
* The value for the Domain attribute contains no embedded dots or
does not start with a dot.
* Domain属性のための値は、埋め込まれたドットを全く含んでいないか、またはドットから始まりません。
* The value for the request-host does not domain-match the Domain
attribute.
* 要求ホストのための値はDomain属性にドメインで合っていません。
* The request-host is a FQDN (not IP address) and has the form HD,
where D is the value of the Domain attribute, and H is a string
that contains one or more dots.
* 要求ホストは、FQDN(IPアドレスでない)であり、フォームHDを持っています、そして、Hは1つ以上のドットを含むストリングです。(そこでは、DがDomain属性の値です)。
Examples:
例:
* A Set-Cookie from request-host y.x.foo.com for Domain=.foo.com
would be rejected, because H is y.x and contains a dot.
* Hがy.xであり、ドットを含んでいるので、Domain=.foo.comであることの要求ホストy.x.foo.comからのSet-クッキーは拒絶されるでしょう。
Kristol & Montulli Standards Track [Page 7] RFC 2109 HTTP State Management Mechanism February 1997
クリストルとMontulli規格はHTTP国家管理メカニズム1997年2月にRFC2109を追跡します[7ページ]。
* A Set-Cookie from request-host x.foo.com for Domain=.foo.com would
be accepted.
* Domain=.foo.comであることの要求ホストx.foo.comからのSet-クッキーを受け入れるでしょう。
* A Set-Cookie with Domain=.com or Domain=.com., will always be
rejected, because there is no embedded dot.
* Domain=.comかDomain=.comがあるSet-クッキー、埋め込まれたドットが全くないので、いつも拒絶されるでしょう。
* A Set-Cookie with Domain=ajax.com will be rejected because the
value for Domain does not begin with a dot.
* Domainのための値がドットで始まらないので、Domain=ajax.comがあるSet-クッキーは拒絶されるでしょう。
4.3.3 Cookie Management
4.3.3 クッキー管理
If a user agent receives a Set-Cookie response header whose NAME is the same as a pre-existing cookie, and whose Domain and Path attribute values exactly (string) match those of a pre-existing cookie, the new cookie supersedes the old. However, if the Set- Cookie has a value for Max-Age of zero, the (old and new) cookie is discarded. Otherwise cookies accumulate until they expire (resources permitting), at which time they are discarded.
先在のクッキーとだれのDomainとPathがまさに(結ぶ)値を結果と考えるかが先在のクッキーのものに合っているときユーザエージェントがNAMEが同じであるSet-クッキー応答ヘッダを受け取るなら、新しいクッキーは老人に取って代わります。 しかしながら、ゼロのマックス-期間、Setクッキーに値があるなら、(古く新しい)のクッキーは捨てられます。 さもなければ、クッキーはどの時に捨てられるかとき期限が切れるまで(リソースが可能にして)蓄積します。
Because user agents have finite space in which to store cookies, they may also discard older cookies to make space for newer ones, using, for example, a least-recently-used algorithm, along with constraints on the maximum number of cookies that each origin server may set.
ユーザエージェントにはクッキーを保存する有限スペースがあるので、また、より新しいもののためのスペースを作るために、より古いクッキーを捨てるかもしれません、例えば最も最近でない中古のアルゴリズムを使用して、それぞれの発生源サーバがセットするかもしれないというクッキーの最大数における規制と共に。
If a Set-Cookie response header includes a Comment attribute, the user agent should store that information in a human-readable form with the cookie and should display the comment text as part of a cookie inspection user interface.
Set-クッキー応答ヘッダがComment属性を入れるなら、ユーザエージェントは、人間読み込み可能なフォームにクッキーでその情報を保存するべきであり、クッキー点検ユーザーインタフェースの一部としてコメントテキストを表示するべきです。
User agents should allow the user to control cookie destruction. An infrequently-used cookie may function as a "preferences file" for network applications, and a user may wish to keep it even if it is the least-recently-used cookie. One possible implementation would be an interface that allows the permanent storage of a cookie through a checkbox (or, conversely, its immediate destruction).
ユーザエージェントはユーザにクッキー破壊を制御させるべきです。 まれに使用されたクッキーはネットワーク応用のための「好みのファイル」として機能するかもしれません、そして、ユーザはそれが最も最近でない中古のクッキーであってもそれを保ちたがっているかもしれません。 1つの可能な実装がチェックボックス(逆に即座の破壊)にクッキーの永久記録媒体の通ることを許すインタフェースでしょう。
Privacy considerations dictate that the user have considerable control over cookie management. The PRIVACY section contains more information.
プライバシー問題は、ユーザにはクッキー管理のかなりのコントロールがあると決めます。 PRIVACY部は詳しい情報を含みます。
4.3.4 Sending Cookies to the Origin Server
4.3.4 発生源サーバにクッキーを送ること。
When it sends a request to an origin server, the user agent sends a Cookie request header to the origin server if it has cookies that are applicable to the request, based on
それが発生源サーバに要求を送るとき、それが要求に適切なクッキーを持っているなら、ユーザエージェントはCookie要求ヘッダーを発生源サーバに送ります、ベースです。
* the request-host;
* 要求ホスト。
Kristol & Montulli Standards Track [Page 8] RFC 2109 HTTP State Management Mechanism February 1997
クリストルとMontulli規格はHTTP国家管理メカニズム1997年2月にRFC2109を追跡します[8ページ]。
* the request-URI;
* 要求URI。
* the cookie's age.
* クッキーの時代。
The syntax for the header is:
ヘッダーのための構文は以下の通りです。
cookie = "Cookie:" cookie-version
1*((";" | ",") cookie-value)
cookie-value = NAME "=" VALUE [";" path] [";" domain]
cookie-version = "$Version" "=" value
NAME = attr
VALUE = value
path = "$Path" "=" value
domain = "$Domain" "=" value
クッキー=、「クッキー:」 クッキー..バージョン..クッキー..値..クッキー..値..等しい..名義..値..経路..ドメイン..クッキー..バージョン..等しい..バージョン..等しい..値..名前..値..値..経路..経路..値..ドメイン..等しい..ドメイン..値
The value of the cookie-version attribute must be the value from the Version attribute, if any, of the corresponding Set-Cookie response header. Otherwise the value for cookie-version is 0. The value for the path attribute must be the value from the Path attribute, if any, of the corresponding Set-Cookie response header. Otherwise the attribute should be omitted from the Cookie request header. The value for the domain attribute must be the value from the Domain attribute, if any, of the corresponding Set-Cookie response header. Otherwise the attribute should be omitted from the Cookie request header.
クッキーバージョン属性の値はもしあればバージョン属性からの対応するSet-クッキー応答ヘッダの値でなければなりません。 さもなければ、クッキーバージョンのための値は0です。 経路属性のための値はもしあればPath属性からの対応するSet-クッキー応答ヘッダの値でなければなりません。 さもなければ、属性はCookie要求ヘッダーから省略されるべきです。 ドメイン属性のための値はもしあればDomain属性からの対応するSet-クッキー応答ヘッダの値でなければなりません。 さもなければ、属性はCookie要求ヘッダーから省略されるべきです。
Note that there is no Comment attribute in the Cookie request header corresponding to the one in the Set-Cookie response header. The user agent does not return the comment information to the origin server.
Comment属性が全くSet-クッキー応答ヘッダというものに対応するCookie要求ヘッダーにないことに注意してください。 ユーザエージェントはコメント情報を発生源サーバに返しません。
The following rules apply to choosing applicable cookie-values from among all the cookies the user agent has.
以下の規則はユーザエージェントが持っているすべてのクッキーから適切なクッキー値を選ぶのに適用されます。
Domain Selection
The origin server's fully-qualified host name must domain-match
the Domain attribute of the cookie.
ドメインSelection、発生源サーバの完全に適切なホスト名はクッキーのDomain属性にドメインで合わなければなりません。
Path Selection
The Path attribute of the cookie must match a prefix of the
request-URI.
Selection Pathが結果と考えるクッキーの経路は要求URIの接頭語に合わなければなりません。
Max-Age Selection
Cookies that have expired should have been discarded and thus
are not forwarded to an origin server.
期限が切れたマックス-時代Selection Cookiesが捨てられるべきであり、その結果、発生源サーバに送られません。
Kristol & Montulli Standards Track [Page 9] RFC 2109 HTTP State Management Mechanism February 1997
クリストルとMontulli規格はHTTP国家管理メカニズム1997年2月にRFC2109を追跡します[9ページ]。
If multiple cookies satisfy the criteria above, they are ordered in the Cookie header such that those with more specific Path attributes precede those with less specific. Ordering with respect to other attributes (e.g., Domain) is unspecified.
複数のクッキーが評価基準を満たすならそれらがCookieヘッダーで上では、注文されるので、より特定のPath属性があるものが以下が特定のそれらに先行します。 他の属性(例えば、Domain)に関して注文するのは不特定です。
Note: For backward compatibility, the separator in the Cookie header is semi-colon (;) everywhere. A server should also accept comma (,) as the separator between cookie-values for future compatibility.
以下に注意してください。 Cookieヘッダーの分離符が後方の互換性のための、セミコロンである、()、いたる所。 また、サーバがコンマを受け入れるべきである、()、将来の互換性のためのクッキー値の間の分離符として。
4.3.5 Sending Cookies in Unverifiable Transactions
4.3.5 立証不可能なトランザクションでクッキーを送ること。
Users must have control over sessions in order to ensure privacy. (See PRIVACY section below.) To simplify implementation and to prevent an additional layer of complexity where adequate safeguards exist, however, this document distinguishes between transactions that are verifiable and those that are unverifiable. A transaction is verifiable if the user has the option to review the request-URI prior to its use in the transaction. A transaction is unverifiable if the user does not have that option. Unverifiable transactions typically arise when a user agent automatically requests inlined or embedded entities or when it resolves redirection (3xx) responses from an origin server. Typically the origin transaction, the transaction that the user initiates, is verifiable, and that transaction may directly or indirectly induce the user agent to make unverifiable transactions.
ユーザには、セッションのコントロールが、秘密を守るためになければなりません。 (下のPRIVACY部を見てください。) 実装を簡素化して、適切であるところで追加層の複雑さを防ぐために、安全装置は存在していて、しかしながら、このドキュメントは証明可能なトランザクションと立証不可能なものを見分けます。 ユーザにトランザクションにおける使用の前に要求URIを見直すオプションがあるなら、トランザクションは証明可能です。 ユーザにそのオプションがないなら、トランザクションは立証不可能です。 ユーザエージェントが自動的に不裏打ちされたか埋め込まれた実体を要求するか、または発生源サーバからリダイレクション(3xx)応答を決議すると、立証不可能なトランザクションは通常起こります。発生源トランザクション(ユーザが開始するトランザクション)は通常、証明可能です、そして、そのトランザクションはユーザエージェントが立証不可能なトランザクションを作るのを直接か間接的に引き起こすかもしれません。
When it makes an unverifiable transaction, a user agent must enable a session only if a cookie with a domain attribute D was sent or received in its origin transaction, such that the host name in the Request-URI of the unverifiable transaction domain-matches D.
立証不可能なトランザクションを作ると、発生源トランザクション(ホストが立証不可能なトランザクションのRequest-URIでドメインマッチをDと命名するようなもの)でドメイン属性Dがあるクッキーを送ったか、または受け取った場合にだけ、ユーザエージェントはセッションを可能にしなければなりません。
This restriction prevents a malicious service author from using unverifiable transactions to induce a user agent to start or continue a session with a server in a different domain. The starting or continuation of such sessions could be contrary to the privacy expectations of the user, and could also be a security problem.
この制限はユーザエージェントが始まるか、または続くのを引き起こす立証不可能なトランザクションを使用するのからの悪意があるサービス作者のために異なったドメインのサーバとのセッションを防ぎます。 そのようなセッションの始めか継続が、ユーザへのプライバシー期待とは逆にあるかもしれなくて、また、警備上の問題であるかもしれません。
User agents may offer configurable options that allow the user agent, or any autonomous programs that the user agent executes, to ignore the above rule, so long as these override options default to "off".
ユーザエージェントは上の規則を無視するために、ユーザエージェントを許容する構成可能なオプション、またはユーザエージェントが実行するどんな自動プログラムも提供するかもしれません、これらがオプションデフォルトを“off"にくつがえす限り。
Many current user agents already provide a review option that would render many links verifiable. For instance, some user agents display the URL that would be referenced for a particular link when the mouse pointer is placed over that link. The user can therefore determine whether to visit that site before causing the browser to do so. (Though not implemented on current user agents, a similar technique could be used for a button used to submit a form -- the user agent
多くの現在のユーザエージェントが既に多くのリンクを証明可能にするレビューオプションを提供します。 例えば、何人かのユーザエージェントがマウス・ポインタがそのリンクの上に置かれるとき特定のリンクに参照をつけられるURLを表示します。 したがって、ユーザは、ブラウザがそうすることを引き起こす前にそのサイトを見るかどうかと決心できます。 (現在のユーザエージェントの上で実装されませんでしたが、フォームを提出するのに使用されるボタンに同様のテクニックを使用できました--、ユーザエージェント
Kristol & Montulli Standards Track [Page 10] RFC 2109 HTTP State Management Mechanism February 1997
クリストルとMontulli規格はHTTP国家管理メカニズム1997年2月にRFC2109を追跡します[10ページ]。
could display the action to be taken if the user were to select that button.) However, even this would not make all links verifiable; for example, links to automatically loaded images would not normally be subject to "mouse pointer" verification.
ユーザがそのボタンを選択するなら、取るために動作を表示できるでしょうに。) しかしながら、これでさえ、すべてのリンクが証明可能になるというわけではないでしょう。 例えば、通常、自動的にロードされたイメージへのリンクは「マウス・ポインタ」検証を受けることがないでしょう。
Many user agents also provide the option for a user to view the HTML source of a document, or to save the source to an external file where it can be viewed by another application. While such an option does provide a crude review mechanism, some users might not consider it acceptable for this purpose.
また、多くのユーザエージェントが、ユーザがドキュメントのHTML源を見るか、または別のアプリケーションでそれを見ることができる外部のファイルにソースを保存するためにオプションを提供します。 そのようなオプションは粗雑なレビューメカニズムを提供しますが、何人かのユーザは、それがこの目的のために許容できると考えないかもしれません。
4.4 How an Origin Server Interprets the Cookie Header
4.4 発生源サーバはどうクッキーヘッダーを解釈するか。
A user agent returns much of the information in the Set-Cookie header to the origin server when the Path attribute matches that of a new request. When it receives a Cookie header, the origin server should treat cookies with NAMEs whose prefix is $ specially, as an attribute for the adjacent cookie. The value for such a NAME is to be interpreted as applying to the lexically (left-to-right) most recent cookie whose name does not have the $ prefix. If there is no previous cookie, the value applies to the cookie mechanism as a whole. For example, consider the cookie
Path属性が新しい要求のものに合っていると、ユーザエージェントはSet-クッキーヘッダーで情報の多くを発生源サーバに返します。 Cookieヘッダーを受けるとき、発生源サーバは特に、接頭語が$であるNAMEsがあるクッキーを扱うべきです、隣接しているクッキーのための属性として。 そのようなNAMEのための値は名前には$接頭語がない辞書的に(まっすぐになるのが残されます)の最新のクッキーに適用しながら解釈されることです。 前のクッキーが全くなければ、値は全体でクッキーメカニズムに適用されます。 例えば、クッキーを考えてください。
Cookie: $Version="1"; Customer="WILE_E_COYOTE";
$Path="/acme"
クッキー: $バージョン=「1インチ」。 顧客は「たくらみの_E_コヨーテ」と等しいです。 「$経路は」 /頂上と等しいです」
$Version applies to the cookie mechanism as a whole (and gives the version number for the cookie mechanism). $Path is an attribute whose value (/acme) defines the Path attribute that was used when the Customer cookie was defined in a Set-Cookie response header.
$バージョンは全体で(そして、クッキーメカニズムのバージョン番号を与える)クッキーメカニズムに適用されます。 $経路は値(/頂上)がCustomerクッキーがSet-クッキー応答ヘッダで定義されたとき使用されたPath属性を定義する属性です。
4.5 Caching Proxy Role
4.5 プロキシの役割をキャッシュすること。
One reason for separating state information from both a URL and document content is to facilitate the scaling that caching permits. To support cookies, a caching proxy must obey these rules already in the HTTP specification:
URLとドキュメント内容の両方と州の情報を切り離す1つの理由はスケーリングを容易にするために、そのキャッシュが可能にするということです。 クッキー、キャッシュにプロキシをサポートするのは既にHTTP仕様でこれらの規則に従わなければなりません:
* Honor requests from the cache, if possible, based on cache validity
rules.
* できれば、キャッシュからの名誉の要求は規則をキャッシュの正当性に基礎づけました。
* Pass along a Cookie request header in any request that the proxy
must make of another server.
* プロキシが別のサーバでしなければならないあらゆる要求でCookie要求ヘッダーを回してください。
* Return the response to the client. Include any Set-Cookie response
header.
* クライアントへの応答を返してください。 あらゆるSet-クッキー応答ヘッダを含めてください。
Kristol & Montulli Standards Track [Page 11] RFC 2109 HTTP State Management Mechanism February 1997
クリストルとMontulli規格はHTTP国家管理メカニズム1997年2月にRFC2109を追跡します[11ページ]。
* Cache the received response subject to the control of the usual
headers, such as Expires, Cache-control: no-cache, and Cache-
control: private,
* Expiresなどの普通のヘッダーのコントロール、Cacheコントロールに容認された応答対象をキャッシュしてください: キャッシュがなく、およびCacheコントロール: 個人的
* Cache the Set-Cookie subject to the control of the usual header,
Cache-control: no-cache="set-cookie". (The Set-Cookie header
should usually not be cached.)
* 普通のヘッダーのコントロール、Cacheコントロールを条件としてSet-クッキーをキャッシュしてください: =「セットクッキー」をキャッシュしないでください。 (通常、Set-クッキーヘッダーをキャッシュするべきではありません。)
Proxies must not introduce Set-Cookie (Cookie) headers of their own in proxy responses (requests).
プロキシはプロキシ応答(要求)でそれら自身のSet-クッキー(クッキー)ヘッダーを紹介してはいけません。
5. EXAMPLES
5. 例
5.1 Example 1
5.1 例1
Most detail of request and response headers has been omitted. Assume the user agent has no stored cookies.
要求と応答ヘッダのほとんどの細部が省略されました。 ユーザエージェントが保存されたクッキーを全く持っていないと仮定してください。
1. User Agent -> Server
1. ユーザエージェント->サーバ
POST /acme/login HTTP/1.1
[form data]
ポスト/acme/login HTTP/1.1[フォームデータ]
User identifies self via a form.
ユーザはフォームで自己を特定します。
2. Server -> User Agent
2. サーバ->ユーザエージェント
HTTP/1.1 200 OK
Set-Cookie: Customer="WILE_E_COYOTE"; Version="1"; Path="/acme"
HTTP/1.1 200OKセットクッキー: 顧客は「たくらみの_E_コヨーテ」と等しいです。 バージョン=「1インチ」。 「経路は」 /頂上と等しいです」
Cookie reflects user's identity.
クッキーはユーザのアイデンティティを反映します。
3. User Agent -> Server
3. ユーザエージェント->サーバ
POST /acme/pickitem HTTP/1.1
Cookie: $Version="1"; Customer="WILE_E_COYOTE"; $Path="/acme"
[form data]
/acme/pickitem HTTP/1.1クッキーを掲示してください: $バージョン=「1インチ」。 顧客は「たくらみの_E_コヨーテ」と等しいです。 「$経路は」 /頂上と等しいです」[フォームデータ]
User selects an item for "shopping basket."
ユーザは「買い物かご」のために項目を選択します。
4. Server -> User Agent
4. サーバ->ユーザエージェント
HTTP/1.1 200 OK
Set-Cookie: Part_Number="Rocket_Launcher_0001"; Version="1";
Path="/acme"
HTTP/1.1 200OKセットクッキー: _数=「ロケット_発射装置_1インチ」を分けてください。 バージョン=「1インチ」。 「経路は」 /頂上と等しいです」
Shopping basket contains an item.
買い物かごは項目を入れてあます。
Kristol & Montulli Standards Track [Page 12] RFC 2109 HTTP State Management Mechanism February 1997
クリストルとMontulli規格はHTTP国家管理メカニズム1997年2月にRFC2109を追跡します[12ページ]。
5. User Agent -> Server
5. ユーザエージェント->サーバ
POST /acme/shipping HTTP/1.1
Cookie: $Version="1";
Customer="WILE_E_COYOTE"; $Path="/acme";
Part_Number="Rocket_Launcher_0001"; $Path="/acme"
[form data]
/acme/shipping HTTP/1.1クッキーを掲示してください: $バージョン=「1インチ」。 顧客は「たくらみの_E_コヨーテ」と等しいです。 「$経路は」 /頂上と等しいです」。 _数=「ロケット_発射装置_1インチ」を分けてください。 「$経路は」 /頂上と等しいです」[フォームデータ]
User selects shipping method from form.
ユーザはフォームから発送法を選択します。
6. Server -> User Agent
6. サーバ->ユーザエージェント
HTTP/1.1 200 OK
Set-Cookie: Shipping="FedEx"; Version="1"; Path="/acme"
HTTP/1.1 200OKセットクッキー: 送料は「フェデックス」と等しいです。 バージョン=「1インチ」。 「経路は」 /頂上と等しいです」
New cookie reflects shipping method.
新しいクッキーは発送法を反映します。
7. User Agent -> Server
7. ユーザエージェント->サーバ
POST /acme/process HTTP/1.1
Cookie: $Version="1";
Customer="WILE_E_COYOTE"; $Path="/acme";
Part_Number="Rocket_Launcher_0001"; $Path="/acme";
Shipping="FedEx"; $Path="/acme"
[form data]
/acme/process HTTP/1.1クッキーを掲示してください: $バージョン=「1インチ」。 顧客は「たくらみの_E_コヨーテ」と等しいです。 「$経路は」 /頂上と等しいです」。 _数=「ロケット_発射装置_1インチ」を分けてください。 「$経路は」 /頂上と等しいです」。 送料は「フェデックス」と等しいです。 「$経路は」 /頂上と等しいです」[フォームデータ]
User chooses to process order.
ユーザは、注文を処理するのを選びます。
8. Server -> User Agent
8. サーバ->ユーザエージェント
HTTP/1.1 200 OK
HTTP/1.1 200OK
Transaction is complete.
トランザクションは完全です。
The user agent makes a series of requests on the origin server, after each of which it receives a new cookie. All the cookies have the same Path attribute and (default) domain. Because the request URLs all have /acme as a prefix, and that matches the Path attribute, each request contains all the cookies received so far.
ユーザエージェントは発生源サーバに関する一連の要求をします。(それはそれのそれぞれ後にサーバのために新しいクッキーを受けます)。 すべてのクッキーには、同じPath属性と(デフォルト)ドメインがあります。 要求URLにはすべて、接頭語として/頂上があって、それがPath属性に合っているので、各要求は今までのところ受け取られているすべてのクッキーを含んでいます。
5.2 Example 2
5.2 例2
This example illustrates the effect of the Path attribute. All detail of request and response headers has been omitted. Assume the user agent has no stored cookies.
この例はPath属性の効果を例証します。 要求と応答ヘッダのすべての細部が省略されました。 ユーザエージェントが保存されたクッキーを全く持っていないと仮定してください。
Imagine the user agent has received, in response to earlier requests, the response headers
ユーザエージェントが以前の要求、応答ヘッダに対応して受信したと想像してください。
Kristol & Montulli Standards Track [Page 13] RFC 2109 HTTP State Management Mechanism February 1997
クリストルとMontulli規格はHTTP国家管理メカニズム1997年2月にRFC2109を追跡します[13ページ]。
Set-Cookie: Part_Number="Rocket_Launcher_0001"; Version="1";
Path="/acme"
セットクッキー: _数=「ロケット_発射装置_1インチ」を分けてください。 バージョン=「1インチ」。 「経路は」 /頂上と等しいです」
and
そして
Set-Cookie: Part_Number="Riding_Rocket_0023"; Version="1";
Path="/acme/ammo"
セットクッキー: 部分_数は「_ロケット_23インチに乗ります」と等しいです。 バージョン=「1インチ」。 経路="/acme/ammo"
A subsequent request by the user agent to the (same) server for URLs of the form /acme/ammo/... would include the following request header:
フォーム/acme/ammo/の…URLのための(同じ)のサーバへのユーザエージェントによるその後の要求は以下の要求ヘッダーを含んでいるでしょう:
Cookie: $Version="1";
Part_Number="Riding_Rocket_0023"; $Path="/acme/ammo";
Part_Number="Rocket_Launcher_0001"; $Path="/acme"
クッキー: $バージョン=「1インチ」。 部分_数は「_ロケット_23インチに乗ります」と等しいです。 $経路="/acme/ammo"。 _数=「ロケット_発射装置_1インチ」を分けてください。 「$経路は」 /頂上と等しいです」
Note that the NAME=VALUE pair for the cookie with the more specific Path attribute, /acme/ammo, comes before the one with the less specific Path attribute, /acme. Further note that the same cookie name appears more than once.
より特定のPath属性があるクッキーのためのNAME=VALUE組(/acme/ammo)がそれほど特定でないPath属性(/頂上)に従ったものに優先することに注意してください。 同じクッキー名が一度より多く見えることにさらに注意してください。
A subsequent request by the user agent to the (same) server for a URL of the form /acme/parts/ would include the following request header:
フォーム/acme/parts/の1つのURLのための(同じ)のサーバへのユーザエージェントによるその後の要求は以下の要求ヘッダーを含んでいるでしょう:
Cookie: $Version="1"; Part_Number="Rocket_Launcher_0001"; $Path="/acme"
クッキー: $バージョン=「1インチ」。 _数=「ロケット_発射装置_1インチ」を分けてください。 「$経路は」 /頂上と等しいです」
Here, the second cookie's Path attribute /acme/ammo is not a prefix of the request URL, /acme/parts/, so the cookie does not get forwarded to the server.
2番目のクッキーのPath属性/acme/ammoがここの、要求URL、/acme/parts/の接頭語でないので、クッキーはサーバに送られません。
6. IMPLEMENTATION CONSIDERATIONS
6. 実装問題
Here we speculate on likely or desirable details for an origin server that implements state management.
ここで、私たちは発生源サーバのための道具が管理を述べるというありそうであるか望ましい詳細を推測します。
6.1 Set-Cookie Content
6.1 セットクッキー内容
An origin server's content should probably be divided into disjoint application areas, some of which require the use of state information. The application areas can be distinguished by their request URLs. The Set-Cookie header can incorporate information about the application areas by setting the Path attribute for each one.
内容がたぶん分割されるべきである発生源サーバのものは応用分野をばらばらにならせます。その或るものは州の情報の使用を必要とします。 それらの要求URLは応用分野を区別できます。 Set-クッキーヘッダーは、Path属性をそれぞれに設定することによって、応用分野の情報を取り入れることができます。
The session information can obviously be clear or encoded text that describes state. However, if it grows too large, it can become unwieldy. Therefore, an implementor might choose for the session information to be a key to a server-side resource. Of course, using
セッション情報は明らかに状態について説明する明確であるかコード化されたテキストであるかもしれません。 しかしながら、大きくなり過ぎるなら、それは扱いにくくなることができます。 したがって、作成者は、セッション情報がサーバサイドリソースのキーであることを選ぶかもしれません。 もちろん使用
Kristol & Montulli Standards Track [Page 14] RFC 2109 HTTP State Management Mechanism February 1997
クリストルとMontulli規格はHTTP国家管理メカニズム1997年2月にRFC2109を追跡します[14ページ]。
a database creates some problems that this state management specification was meant to avoid, namely:
データベースがこの国家管理仕様が避けることになっていたいくつかの問題を生じさせる、すなわち:
1. keeping real state on the server side;
1. サーバ側のキープ実況。
2. how and when to garbage-collect the database entry, in case the
user agent terminates the session by, for example, exiting.
2. ユーザエージェントが例えば、出ることによってセッションを終えるといけないので、どのように、いつデータベースエントリーをゴミで集めますか?
6.2 Stateless Pages
6.2 状態がないページ
Caching benefits the scalability of WWW. Therefore it is important to reduce the number of documents that have state embedded in them inherently. For example, if a shopping-basket-style application always displays a user's current basket contents on each page, those pages cannot be cached, because each user's basket's contents would be different. On the other hand, if each page contains just a link that allows the user to "Look at My Shopping Basket", the page can be cached.
キャッシュはWWWのスケーラビリティのためになります。したがって、本来状態をそれらに埋め込むドキュメントの数を減少させるのは重要です。 例えば、買い物かごのスタイルアプリケーションがいつも各ページのユーザの現在のかごのコンテンツを表示するなら、それらのページをキャッシュできません、各ユーザのかごのコンテンツは異なっているでしょう、したがって。 他方では、各ページがまさしくユーザが「私の買い物かごを見ること」を許容するリンクを含んでいるなら、ページをキャッシュできます。
6.3 Implementation Limits
6.3 実装限界
Practical user agent implementations have limits on the number and size of cookies that they can store. In general, user agents' cookie support should have no fixed limits. They should strive to store as many frequently-used cookies as possible. Furthermore, general-use user agents should provide each of the following minimum capabilities individually, although not necessarily simultaneously:
実用的なユーザエージェント実装はそれらが保存できるクッキーの数とサイズに限界を持っています。 一般に、ユーザエージェントのクッキーサポートには、固定限界が全くあるべきではありません。 彼らは、できるだけ多くの頻繁に使用されたクッキーを保存するように努力するべきです。 その上、必ず同時であるというわけではありませんが、一般的使用ユーザエージェントは個別にそれぞれの以下の最小の能力を提供するべきです:
* at least 300 cookies
* 少なくとも300個のクッキー
* at least 4096 bytes per cookie (as measured by the size of the
characters that comprise the cookie non-terminal in the syntax
description of the Set-Cookie header)
* 1クッキーあたり少なくとも4096バイト(Set-クッキーヘッダーの構文記述における非端末のクッキーを包括するキャラクタのサイズによって測定されるように)
* at least 20 cookies per unique host or domain name
* 少なくともユニークなホストあたりの20クッキーかドメイン名
User agents created for specific purposes or for limited-capacity devices should provide at least 20 cookies of 4096 bytes, to ensure that the user can interact with a session-based origin server.
明確な目標か収容数の限界デバイスのために創造されたユーザエージェントは、ユーザがセッションベースの発生源サーバと対話できるのを保証するために4096バイトの少なくとも20個のクッキーを提供するべきです。
The information in a Set-Cookie response header must be retained in its entirety. If for some reason there is inadequate space to store the cookie, it must be discarded, not truncated.
Set-クッキー応答ヘッダの情報を全体として保有しなければなりません。 クッキーを保存するために不十分なスペースがあれば、先端を切られるのではなく、それを捨てなければなりません。
Applications should use as few and as small cookies as possible, and they should cope gracefully with the loss of a cookie.
アプリケーションはできるだけわずかで小さいクッキーを使用するべきです、そして、それらは優雅にクッキーの損失を切り抜けるべきです。
Kristol & Montulli Standards Track [Page 15] RFC 2109 HTTP State Management Mechanism February 1997
クリストルとMontulli規格はHTTP国家管理メカニズム1997年2月にRFC2109を追跡します[15ページ]。
6.3.1 Denial of Service Attacks
6.3.1 サービス不能攻撃
User agents may choose to set an upper bound on the number of cookies to be stored from a given host or domain name or on the size of the cookie information. Otherwise a malicious server could attempt to flood a user agent with many cookies, or large cookies, on successive responses, which would force out cookies the user agent had received from other servers. However, the minima specified above should still be supported.
ユーザエージェントは、クッキーの数に関する上限に与えられたホストかドメイン名かクッキー情報のサイズの上に保存されるように設定するのを選ぶかもしれません。 さもなければ、悪意があるサーバは、多くのクッキー、または大きいクッキーでユーザエージェントをあふれさせるのを試みるかもしれません、連続した応答に関して。(応答はユーザエージェントが他のサーバから受け取ったクッキーを追い出すでしょう)。 しかしながら、上で指定されたminimaはまだサポートされているべきです。
7. PRIVACY
7. プライバシー
7.1 User Agent Control
7.1 ユーザエージェントコントロール
An origin server could create a Set-Cookie header to track the path of a user through the server. Users may object to this behavior as an intrusive accumulation of information, even if their identity is not evident. (Identity might become evident if a user subsequently fills out a form that contains identifying information.) This state management specification therefore requires that a user agent give the user control over such a possible intrusion, although the interface through which the user is given this control is left unspecified. However, the control mechanisms provided shall at least allow the user
発生源サーバは、サーバを通してユーザの経路を追跡するためにSet-クッキーヘッダーを創造するかもしれません。ユーザは情報の押しつけがましい蓄積としてこの振舞いに反対するかもしれません、彼らのアイデンティティが明白でなくても。 (ユーザが次に身元が分かる情報を含む書類に書き込むなら、アイデンティティは明白になるかもしれません。) したがって、この国家管理仕様は、ユーザエージェントがそのような可能な侵入のユーザ支配力を与えるのを必要とします、この支配力がユーザに与えられているインタフェースが不特定のままにされますが。 しかしながら、メカニズムが提供したコントロールはユーザを少なくとも許容するものとします。
* to completely disable the sending and saving of cookies.
* クッキーの発信と節約を完全に無効にするために。
* to determine whether a stateful session is in progress.
* statefulセッションが進行しているかどうか決定するために。
* to control the saving of a cookie on the basis of the cookie's
Domain attribute.
* クッキーのDomain属性に基づいてクッキーの節約を制御するために。
Such control could be provided by, for example, mechanisms
例えば、メカニズムはそのようなコントロールを提供できました。
* to notify the user when the user agent is about to send a cookie
to the origin server, offering the option not to begin a session.
* ユーザエージェントが発生源サーバにクッキーを送ろうとしているとき、開会しないようにオプションを提供して、ユーザに通知するために。
* to display a visual indication that a stateful session is in
progress.
* statefulセッションが進行しているという視覚指示を表示するために。
* to let the user decide which cookies, if any, should be saved
when the user concludes a window or user agent session.
* ユーザが窓かユーザエージェントセッションを結論づけると、ユーザにどのクッキーについてもしあれば決めさせるかは保存されるべきです。
* to let the user examine the contents of a cookie at any time.
* ユーザにいつでもクッキーのコンテンツを調べさせるように。
A user agent usually begins execution with no remembered state information. It should be possible to configure a user agent never to send Cookie headers, in which case it can never sustain state with
通常、ユーザエージェントは覚えていられた州の情報なしで実行を始めます。 それはユーザエージェントを構成しても、Cookieヘッダーを決して送らないのにおいて決してどのケースで状態を支えることができるかに可能であるべきではありません。
Kristol & Montulli Standards Track [Page 16] RFC 2109 HTTP State Management Mechanism February 1997
クリストルとMontulli規格はHTTP国家管理メカニズム1997年2月にRFC2109を追跡します[16ページ]。
an origin server. (The user agent would then behave like one that is unaware of how to handle Set-Cookie response headers.)
発生源サーバ。(次に、ユーザエージェントはどうSet-クッキー応答ヘッダを扱うかに気づかないもののように振る舞うでしょう。)
When the user agent terminates execution, it should let the user discard all state information. Alternatively, the user agent may ask the user whether state information should be retained; the default should be "no". If the user chooses to retain state information, it would be restored the next time the user agent runs.
ユーザエージェントが実行を終えると、ユーザはそれですべての州の情報を捨てることができるべきです。 あるいはまた、ユーザエージェントは、州の情報が保有されるべきであるかどうかユーザに尋ねるかもしれません。 デフォルトは「いいえ」であるべきです。 ユーザが、州の情報を保有するのを選ぶなら、それはユーザエージェントが走る次の時に回復するでしょう。
NOTE: User agents should probably be cautious about using files to store cookies long-term. If a user runs more than one instance of the user agent, the cookies could be commingled or otherwise messed up.
以下に注意してください。 ユーザエージェントはたぶんクッキー長期を保存するのにファイルを使用することに関して用心深いはずです。 ユーザがユーザエージェントの1つ以上のインスタンスを実行するなら、クッキーは、混ぜ合わせられるか、または別の方法で台無しにされるかもしれません。
7.2 Protocol Design
7.2 プロトコルデザイン
The restrictions on the value of the Domain attribute, and the rules concerning unverifiable transactions, are meant to reduce the ways that cookies can "leak" to the "wrong" site. The intent is to restrict cookies to one, or a closely related set of hosts. Therefore a request-host is limited as to what values it can set for Domain. We consider it acceptable for hosts host1.foo.com and host2.foo.com to share cookies, but not a.com and b.com.
Domain属性の値における制限、および立証不可能なトランザクションに関する規則はクッキーが「間違った」サイトに「漏れることができる」方法を減少させることになっています。 意図は1つへのクッキー、または密接に関係づけられたセットのホストを制限することです。 したがって、それがどんな値をDomainに設定できるかに関して要求ホストは制限されます。 私たちは、ホストのhost1.foo.comとhost2.foo.comがa.comとb.comではなく、クッキーを共有するのが、許容できると考えます。
Similarly, a server can only set a Path for cookies that are related to the request-URI.
同様に、サーバは要求URIに関連するクッキーにPathを設定できるだけです。
8. SECURITY CONSIDERATIONS
8. セキュリティ問題
8.1 Clear Text
8.1 クリアテキスト
The information in the Set-Cookie and Cookie headers is unprotected. Two consequences are:
Set-クッキーとCookieヘッダーの情報は保護がありません。 2つの結果は以下の通りです。
1. Any sensitive information that is conveyed in them is exposed
to intruders.
1. それらで伝えられるどんな機密情報も侵入者に暴露されます。
2. A malicious intermediary could alter the headers as they travel
in either direction, with unpredictable results.
2. 彼らが予測できない結果でどちらの方向にも旅行するとき、悪意がある仲介者はヘッダーを変更できました。
These facts imply that information of a personal and/or financial nature should only be sent over a secure channel. For less sensitive information, or when the content of the header is a database key, an origin server should be vigilant to prevent a bad Cookie value from causing failures.
これらの事実は、個人的な、そして/または、財政的な自然の情報が安全なチャンネルの上に送られるだけであるべきであるのを含意します。 より少ない機密情報かそれともいつヘッダーの内容がデータベースキーであるか間、発生源サーバは、悪いCookie値が失敗を引き起こすのを防ぐために用心深いはずです。
Kristol & Montulli Standards Track [Page 17] RFC 2109 HTTP State Management Mechanism February 1997
クリストルとMontulli規格はHTTP国家管理メカニズム1997年2月にRFC2109を追跡します[17ページ]。
8.2 Cookie Spoofing
8.2 クッキースプーフィング
Proper application design can avoid spoofing attacks from related domains. Consider:
正当な適用デザインは、関連するドメインから攻撃を偽造するのを避けることができます。 考えます:
1. User agent makes request to victim.cracker.edu, gets back
cookie session_id="1234" and sets the default domain
victim.cracker.edu.
1. ユーザエージェントは、要求をvictim.cracker.eduにして、クッキーセッション_イド=「1234」を取り戻して、デフォルトドメインvictim.cracker.eduを設定します。
2. User agent makes request to spoof.cracker.edu, gets back
cookie session-id="1111", with Domain=".cracker.edu".
2. ユーザエージェントは、要求をspoof.cracker.eduにして、クッキーセッションイド=Domainがある「1111」=".cracker.edu"を取り戻します。
3. User agent makes request to victim.cracker.edu again, and
passes
3. ユーザエージェントは、再び要求をvictim.cracker.eduにして、通ります。
Cookie: $Version="1";
session_id="1234";
session_id="1111"; $Domain=".cracker.edu"
クッキー: $バージョン=「1インチ」。 セッション_イド=「1234」。 セッション_イド=「1111」。 $ドメイン=".cracker.edu"
The server at victim.cracker.edu should detect that the second
cookie was not one it originated by noticing that the Domain
attribute is not for itself and ignore it.
victim.cracker.eduのサーバは検出されるべきです。2番目のクッキーは、Domain属性がそれ自体のためのものでないのに気付くことによってそれが溯源したというわけではない1つであり、それを無視します。
8.3 Unexpected Cookie Sharing
8.3 予期していなかったクッキー共有
A user agent should make every attempt to prevent the sharing of session information between hosts that are in different domains. Embedded or inlined objects may cause particularly severe privacy problems if they can be used to share cookies between disparate hosts. For example, a malicious server could embed cookie information for host a.com in a URI for a CGI on host b.com. User agent implementors are strongly encouraged to prevent this sort of exchange whenever possible.
ユーザエージェントは、セッション情報の共有を防ぐために異なったドメインにいるホストの間で最善の努力をするべきです。 異種のホストの間のクッキーを共有するのにそれらを使用できるなら、埋め込まれたか不裏打ちされたオブジェクトは特に厳しいプライバシー問題を引き起こすかもしれません。 例えば、悪意があるサーバはホストa.comのためにホストb.comでクッキー情報をCGIのためのURIに埋め込むかもしれません。 可能であるときはいつも、ユーザエージェントの作成者がこの種類の交換を防ぐよう強く奨励されます。
9. OTHER, SIMILAR, PROPOSALS
9. 他の、そして、同様の提案
Three other proposals have been made to accomplish similar goals. This specification is an amalgam of Kristol's State-Info proposal and Netscape's Cookie proposal.
同様の目標を達成するのを他の3つの提案をしました。 この仕様はクリストルの州-インフォメーション提案とNetscapeのCookie提案のアマルガムです。
Brian Behlendorf proposed a Session-ID header that would be user- agent-initiated and could be used by an origin server to track "clicktrails". It would not carry any origin-server-defined state, however. Phillip Hallam-Baker has proposed another client-defined session ID mechanism for similar purposes.
ブライアンBehlendorfはエージェントによって開始されていた状態でユーザであるSession-IDヘッダーを提案して、発生源サーバによって使用されて、"clicktrails"を追跡できました。 しかしながら、それは少しの定義された発生源サーバ状態も運ばないでしょう。フィリップ・ハラム-ベイカーは同様の目的のために別のクライアントによって定義されたセッションIDメカニズムを提案しました。
Kristol & Montulli Standards Track [Page 18] RFC 2109 HTTP State Management Mechanism February 1997
クリストルとMontulli規格はHTTP国家管理メカニズム1997年2月にRFC2109を追跡します[18ページ]。
While both session IDs and cookies can provide a way to sustain stateful sessions, their intended purpose is different, and, consequently, the privacy requirements for them are different. A user initiates session IDs to allow servers to track progress through them, or to distinguish multiple users on a shared machine. Cookies are server-initiated, so the cookie mechanism described here gives users control over something that would otherwise take place without the users' awareness. Furthermore, cookies convey rich, server- selected information, whereas session IDs comprise user-selected, simple information.
セッションIDとクッキーの両方がstatefulセッションを支える方法を提供できますが、それらの本来の目的は異なっています、そして、その結果、それらのためのプライバシー要件は異なっています。 ユーザは、サーバがそれらを通した進歩を追跡するか、または共有されたマシンの上の複数のユーザを区別するのを許容するためにセッションIDを開始します。 クッキーがサーバによって開始されているので、ここで説明されたクッキーメカニズムはそうでなければユーザの認識なしで行われる何かの支配力をユーザに与えます。 その上、クッキーは金持ちを運びますが、サーバは情報を選択しましたが、セッションIDはユーザによって選択されて、簡単な情報を包括します。
10. HISTORICAL
10. 歴史的
10.1 Compatibility With Netscape's Implementation
10.1 Netscapeの実装との互換性
HTTP/1.0 clients and servers may use Set-Cookie and Cookie headers that reflect Netscape's original cookie proposal. These notes cover inter-operation between "old" and "new" cookies.
HTTP/1.0のクライアントとサーバがSet-クッキーとNetscapeのオリジナルのクッキー提案を反映するCookieヘッダーを使用するかもしれません。 これらの注意は「古く」て「新しい」クッキーの間の相互操作をカバーしています。
10.1.1 Extended Cookie Header
10.1.1 拡張クッキーヘッダー
This proposal adds attribute-value pairs to the Cookie request header in a compatible way. An "old" client that receives a "new" cookie will ignore attributes it does not understand; it returns what it does understand to the origin server. A "new" client always sends cookies in the new form.
この提案はコンパチブル方法でCookie要求ヘッダーに属性値組を加えます。 「新しい」クッキーを受け取る「古い」クライアントはそれが理解していない属性を無視するでしょう。 それは発生源サーバに理解しているものを返します。「新しい」クライアントは新しいフォームでいつもクッキーを送ります。
An "old" server that receives a "new" cookie will see what it thinks are many cookies with names that begin with a $, and it will ignore them. (The "old" server expects these cookies to be separated by semi-colon, not comma.) A "new" server can detect cookies that have passed through an "old" client, because they lack a $Version attribute.
「新しい」クッキーを受ける「古い」サーバはそれがドルで始まる名前がある多くのクッキーであると考えるものを見るでしょう、そして、それはそれらを無視するでしょう。 (「古い」サーバは、これらのクッキーがコンマではなく、セミコロンによって切り離されると予想します。) 「新しい」サーバは$バージョン属性を欠いているので「古い」クライアントを通り抜けたクッキーを検出できます。
10.1.2 Expires and Max-Age
10.1.2、期限が切れて、マックスと同じくらい年をとります。
Netscape's original proposal defined an Expires header that took a date value in a fixed-length variant format in place of Max-Age:
Netscapeの起案はマックス-時代に代わって固定長異形形式で日付の値を取ったExpiresヘッダーを定義しました:
Wdy, DD-Mon-YY HH:MM:SS GMT
Wdy、DD月曜日のYY HH、: mm: グリニッジ標準時のSS
Note that the Expires date format contains embedded spaces, and that "old" cookies did not have quotes around values. Clients that implement to this specification should be aware of "old" cookies and Expires.
Expires日付の形式が埋め込まれた空間を含んでいて、「古い」クッキーが値の周りに引用文を持っていなかったことに注意してください。 これに仕様を履行するクライアントは「古い」クッキーとExpiresを意識しているべきです。
Kristol & Montulli Standards Track [Page 19] RFC 2109 HTTP State Management Mechanism February 1997
クリストルとMontulli規格はHTTP国家管理メカニズム1997年2月にRFC2109を追跡します[19ページ]。
10.1.3 Punctuation
10.1.3 句読
In Netscape's original proposal, the values in attribute-value pairs
did not accept "-quoted strings. Origin servers should be cautious
about sending values that require quotes unless they know the
receiving user agent understands them (i.e., "new" cookies). A
("new") user agent should only use quotes around values in Cookie
headers when the cookie's version(s) is (are) all compliant with this
specification or later.
Netscapeの起案では、属性値組の値は「引用文字列」を受け入れませんでした。 発生源サーバは受信ユーザエージェントがそれら(すなわち、「新しい」クッキー)を理解しているのを知らないなら引用文を必要とする送付値に関して用心深いはずです。 ユーザエージェントが使用するだけであるべきである(「新しい」)はCookieで値の周りでこの仕様で言いなりになるか、または、より遅れていた状態でクッキーのバージョンが(あります)すべてであるヘッダーを引用します。
In Netscape's original proposal, no whitespace was permitted around the = that separates attribute-value pairs. Therefore such whitespace should be used with caution in new implementations.
Netscapeの起案では、空白は全く属性値組を切り離す=の周りで受入れられませんでした。 したがって、そのような空白は新しい実装に慎重に使用されるべきです。
10.2 Caching and HTTP/1.0
10.2 キャッシュとHTTP/1.0
Some caches, such as those conforming to HTTP/1.0, will inevitably cache the Set-Cookie header, because there was no mechanism to suppress caching of headers prior to HTTP/1.1. This caching can lead to security problems. Documents transmitted by an origin server along with Set-Cookie headers will usually either be uncachable, or will be "pre-expired". As long as caches obey instructions not to cache documents (following Expires: <a date in the past> or Pragma: no-cache (HTTP/1.0), or Cache-control: no-cache (HTTP/1.1)) uncachable documents present no problem. However, pre-expired documents may be stored in caches. They require validation (a conditional GET) on each new request, but some cache operators loosen the rules for their caches, and sometimes serve expired documents without first validating them. This combination of factors can lead to cookies meant for one user later being sent to another user. The Set-Cookie header is stored in the cache, and, although the document is stale (expired), the cache returns the document in response to later requests, including cached headers.
HTTP/1.0に従うものなどのいくつかのキャッシュが必然的にSet-クッキーヘッダーをキャッシュするでしょう、HTTP/1.1の前にヘッダーのキャッシュを抑圧するためにメカニズムが全くなかったので。 このキャッシュは警備上の問題に通じることができます。Set-クッキーヘッダーに伴う発生源サーバによって伝えられたドキュメントは、通常、非キャッシュ可能であるか、または「あらかじめ吐き出されるでしょう」。 キャッシュがドキュメント(次のExpires: <過去の>かPragmaの日付: キャッシュがない(HTTP/1.0)、またはCache-コントロール: キャッシュがない(HTTP/1.1))をキャッシュしないように指示に従う限り、非キャッシュ可能ドキュメントは問題を全く提示しません。 しかしながら、プレ満期のドキュメントはキャッシュで保存されるかもしれません。 彼らがそれぞれの新しい要求のときに合法化(条件付きのGET)を必要としますが、最初にそれらを有効にしないで、何人かのキャッシュオペレータが、それらのキャッシュのために規則を緩和して、時々満期のドキュメントに役立ちます。 要素のこの組み合わせは、別のユーザに送りながら、後での1人のユーザのために作られていたクッキーに通じることができます。 Set-クッキーヘッダーはキャッシュで保存されます、そして、ドキュメントは聞き古したです(吐き出されます)、キャッシュは後の要求に対応してドキュメントを返します、キャッシュされたヘッダーを含んでいて。
11. ACKNOWLEDGEMENTS
11. 承認
This document really represents the collective efforts of the following people, in addition to the authors: Roy Fielding, Marc Hedlund, Ted Hardie, Koen Holtman, Shel Kaphan, Rohit Khare.
このドキュメントは本当に作者に加えた以下の人々の結集した力を表します: ロイFielding、マーク・ヘドランド、テッド・ハーディー、クンHoltman、シェルKaphan、Rohit Khare。
Kristol & Montulli Standards Track [Page 20] RFC 2109 HTTP State Management Mechanism February 1997
クリストルとMontulli規格はHTTP国家管理メカニズム1997年2月にRFC2109を追跡します[20ページ]。
12. AUTHORS' ADDRESSES
12. 作者のアドレス
David M. Kristol Bell Laboratories, Lucent Technologies 600 Mountain Ave. Room 2A-227 Murray Hill, NJ 07974
デヴィッドM.クリストルベル研究所、ルーセントテクノロジーズ600山のAve。 ニュージャージー 余地の2A-227マレー丘、07974
Phone: (908) 582-2250 Fax: (908) 582-5809 EMail: dmk@bell-labs.com
以下に電話をしてください。 (908) 582-2250 Fax: (908) 582-5809 メールしてください: dmk@bell-labs.com
Lou Montulli Netscape Communications Corp. 501 E. Middlefield Rd. Mountain View, CA 94043
ルウMontulliネットスケープ・コミュニケーションズ501E.Middlefield通り マウンテンビュー、カリフォルニア 94043
Phone: (415) 528-2600 EMail: montulli@netscape.com
以下に電話をしてください。 (415) 528-2600 メールしてください: montulli@netscape.com
Kristol & Montulli Standards Track [Page 21]
クリストルとMontulli標準化過程[21ページ]
一覧
スポンサーリンク
