RFC2295 日本語訳
2295 Transparent Content Negotiation in HTTP. K. Holtman, A. Mutz. March 1998. (Format: TXT=125130 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group K. Holtman
Request for Comments: 2295 TUE
Category: Experimental A. Mutz
Hewlett-Packard
March 1998
Holtmanがコメントのために要求するワーキンググループK.をネットワークでつないでください: 2295年の火曜日のカテゴリ: 1998年の実験的なA.Mutzヒューレット・パッカードの行進
Transparent Content Negotiation in HTTP
HTTPにおけるわかりやすい満足している交渉
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
ABSTRACT
要約
HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is an extensible negotiation mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed. This enables the smooth deployment of new web data formats and markup tags.
HTTPで、ウェブサイトの作者は同じ情報の複数のバージョンをただ一つのURLの下に置くことができます。 わかりやすい満足している交渉はHTTPの上で層にされた、広げることができる交渉メカニズムです、URLがアクセスされているとき自動的に最も良いバージョンを選択するために。 これは新しいウェブデータ形式とマーク付けタグの滑らかな展開を可能にします。
TABLE OF CONTENTS
目次
1 Introduction................................................4
1.1 Background................................................4
1つの序論…4 1.1バックグラウンド…4
2 Terminology.................................................5
2.1 Terms from HTTP/1.1.......................................5
2.2 New terms.................................................6
2用語…5 HTTP/1.1からの2.1の用語…5 2.2回の新学期…6
3 Notation....................................................8
3記法…8
4 Overview....................................................9
4.1 Content negotiation.......................................9
4.2 HTTP/1.0 style negotiation scheme.........................9
4.3 Transparent content negotiation scheme...................10
4.4 Optimizing the negotiation process.......................12
4.5 Downwards compatibility with non-negotiating user agents.14
4.6 Retrieving a variant by hand.............................15
4.7 Dimensions of negotiation................................15
4概要…9 4.1 満足している交渉…9 4.2 HTTP/1.0は交渉体系を流行に合わせます…9 4.3の透明な満足している交渉体系…10 4.4 交渉を最適化して、処理してください…12、4.5、下向きである、手による非交渉しているユーザエージェント.14 4.6Retrieving a異形との互換性…15 交渉の4.7次元…15
Holtman & Mutz Experimental [Page 1] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[1ページ]RFC2295
4.8 Feature negotiation......................................15
4.9 Length of variant lists..................................16
4.10 Relation with other negotiation schemes.................16
4.8 交渉を特徴としてください…15 4.9 異形の長さは記載します…16 4.10 他の交渉との関係は計画されます…16
5 Variant descriptions.......................................17
5.1 Syntax...................................................17
5.2 URI......................................................17
5.3 Source-quality...........................................18
5.4 Type, charset, language, and length......................19
5.5 Features.................................................19
5.6 Description..............................................19
5.7 Extension-attribute......................................20
5 異形記述…17 5.1構文…17 5.2URI…17 5.3ソース品質…18 5.4のタイプ、charset、言語、および長さ…19 5.5 特集します。19 5.6記述…19 5.7拡大属性…20
6 Feature negotiation........................................20
6.1 Feature tags.............................................20
6.1.1 Feature tag values.....................................21
6.2 Feature sets.............................................21
6.3 Feature predicates.......................................22
6.4 Features attribute.......................................24
6 交渉を特徴としてください…20 6.1 タグを特集してください…20 6.1 .1 タグ値を特徴としてください…21 6.2 セットを特集してください…21 6.3 述部を特徴としてください…22 6.4 属性を特徴とします…24
7 Remote variant selection algorithms........................25
7.1 Version numbers..........................................25
7 リモート異形選択アルゴリズム…25 7.1 バージョン番号…25
8 Content negotiation status codes and headers...............25
8.1 506 Variant Also Negotiates..............................25
8.2 Accept-Features..........................................26
8.3 Alternates...............................................27
8.4 Negotiate................................................28
8.5 TCN......................................................30
8.6 Variant-Vary.............................................30
8個の満足している交渉ステータスコードとヘッダー…25 また、8.1 506異形は交渉されます…25 8.2 特徴を受け入れます…26 8.3 交替します…27 8.4 交渉してください…28 8.5TCN…30 8.6 異形で異なってください…30
9 Cache validators...........................................31
9.1 Variant list validators..................................31
9.2 Structured entity tags...................................31
9.3 Assigning entity tags to variants........................32
9 validatorsをキャッシュしてください…31 9.1異形リストvalidators…31 9.2は実体タグを構造化しました…31 9.3 実体タグを異形に割り当てます…32
10 Content negotiation responses..............................32
10.1 List response...........................................33
10.2 Choice response.........................................34
10.3 Adhoc response..........................................37
10.4 Reusing the Alternates header...........................38
10.5 Extracting a normal response from a choice response.....39
10.6 Elaborate Vary headers..................................39
10.6.1 Construction of an elaborate Vary header..............40
10.6.2 Caching of an elaborate Vary header...................41
10.7 Adding an Expires header for HTTP/1.0 compatibility.....41
10.8 Negotiation on content encoding.........................41
10 満足している交渉応答…32 10.1 応答を記載してください…33 10.2 特選している応答…34 10.3 Adhoc応答…37 10.4 Alternatesヘッダーを再利用します…38 10.5 特選している応答から通常の応答を抽出します…39 10.6 Varyヘッダーを練ってください…39 10.6.1 細かいVaryヘッダーの構造…40 10.6.2 細かいVaryヘッダーのキャッシュ…41 10.7 HTTP/1.0の互換性のためにExpiresヘッダーを加えます…満足しているコード化の41 10.8交渉…41
Holtman & Mutz Experimental [Page 2] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[2ページ]RFC2295
11 User agent support for transparent negotiation.............42
11.1 Handling of responses...................................42
11.2 Presentation of a transparently negotiated resource.....42
11 わかりやすい交渉のユーザエージェントサポート…42 11.1 応答の取り扱い…42 11.2 透過的に交渉されたリソースのプレゼンテーション…42
12 Origin server support for transparent negotiation..........43
12.1 Requirements............................................43
12.2 Negotiation on transactions other than GET and HEAD.....45
12 わかりやすい交渉の発生源サーバサポート…43 12.1の要件…GETとHEAD以外のトランザクションの43 12.2交渉…45
13 Proxy support for transparent negotiation..................45
13 わかりやすい交渉のプロキシサポート…45
14 Security and privacy considerations........................46
14.1 Accept- headers revealing personal information..........46
14.2 Spoofing of responses from variant resources............47
14.3 Security holes revealed by negotiation..................47
14 セキュリティとプライバシー問題…46 14.1 個人情報を明らかにするヘッダーを受け入れてください…異形リソースからの応答の46 14.2スプーフィング…47 14.3 交渉で明らかにされたセキュリティ穴…47
15 Internationalization considerations........................47
15 国際化問題…47
16 Acknowledgments............................................47
16の承認…47
17 References.................................................48
17の参照箇所…48
18 Authors' Addresses.........................................48
18人の作者のアドレス…48
19 Appendix: Example of a local variant selection algorithm...49
19.1 Computing overall quality values........................49
19.2 Determining the result..................................51
19.3 Ranking dimensions......................................51
19付録: ローカルの異形選択アルゴリズムに関する例…49 19.1 総合的な上質の値を計算します…49 19.2 結果を決定します…51 19.3 寸法を格付けします…51
20 Appendix: feature negotiation examples.....................52
20.1 Use of feature tags.....................................52
20.2 Use of numeric feature tags.............................53
20.3 Feature tag design......................................53
20付録: 交渉の例を特徴としてください…52 20.1 特徴タグの使用…52 20.2 数値特徴タグの使用…53 20.3 タグデザインを特徴としてください…53
21 Appendix: origin server implementation considerations......54
21.1 Implementation with a CGI script........................54
21.2 Direct support by HTTP servers..........................55
21.3 Web publishing tools....................................55
21付録: 発生源サーバ実装問題…CGIスクリプトがある54 21.1実装…54 21.2 HTTPサーバはサポートを指示してください…55 21.3 ウェブパブリッシングツール…55
22 Appendix: Example of choice response construction..........55
22付録: 特選している応答工事に関する例…55
23 Full Copyright Statement...................................58
23 完全な著作権宣言文…58
Holtman & Mutz Experimental [Page 3] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[3ページ]RFC2295
1 Introduction
1つの序論
HTTP allows web site authors to put multiple versions of the same information under a single URI. Each of these versions is called a `variant'. Transparent content negotiation is an extensible negotiation mechanism for automatically and efficiently retrieving the best variant when a GET or HEAD request is made. This enables the smooth deployment of new web data formats and markup tags.
HTTPで、ウェブサイトの作者は同じ情報の複数のバージョンをただ一つのURIの下に置くことができます。 それぞれのこれらのバージョンは'異形'と呼ばれます。 わかりやすい満足している交渉は、GETかHEAD要求をするとき自動的に効率的に最も良い異形を検索するための広げることができる交渉メカニズムです。 これは新しいウェブデータ形式とマーク付けタグの滑らかな展開を可能にします。
This specification defines transparent content negotiation as an extension on top of the HTTP/1.1 protocol [1]. However, use of this extension does not require use of HTTP/1.1: transparent content negotiation can also be done if some or all of the parties are HTTP/1.0 [2] systems.
この仕様はHTTP/1.1プロトコル[1]の上でわかりやすい満足している交渉を拡大と定義します。 しかしながら、この拡張子の使用はHTTP/1.1の使用を必要としません: また、いくつかかパーティーが皆、HTTP/1.0台の[2]システムであるならわかりやすい満足している交渉ができます。
Transparent content negotiation is called `transparent' because it makes all variants which exist inside the origin server visible to outside parties.
パーティーにおいて、目に見える発生源サーバで存在するすべての異形を作るので、わかりやすい満足している交渉は'透明である'と呼ばれます。
Note: Some members of the IETF are currently undertaking a number
of activities which are loosely related to this experimental
protocol. First, there is an effort to define a protocol-
independent registry for feature tags. The intention is that this
experimental protocol will be one of the clients of the registry.
Second, some research is being done on content negotiation systems
for other transport protocols (like internet mail and internet fax)
and on generalized negotiation systems for multiple transport
protocols. At the time of writing, it is unclear if or when this
research will lead to results in the form of complete negotiation
system specifications. It is also unclear to which extent possible
future specifications can or will re-use elements of this
experimental protocol.
以下に注意してください。 IETFのメンバーの中には現在緩くこの実験プロトコルに関連する多くの活動を引き受けている人もいます。 まず最初に、特徴タグのためにプロトコルの独立している登録を定義するために、取り組みがあります。 意志はこの実験プロトコルが登録のクライアントのひとりになるということです。 2番目に、他のトランスポート・プロトコル(インターネットメールとインターネットファックスのような)の満足している交渉システムの上と、そして、複数のトランスポート・プロトコルの一般化された交渉システムの上で何らかの研究をしています。 これを書いている時点で、それが不明瞭である、または、この研究はいつ完全な交渉システム仕様の形で結果につながるだろうか。 また、仕様がどの範囲の可能な未来まで使用できるか、またはこの実験プロトコルの原理を再使用するかも、不明瞭です。
1.1 Background
1.1 バックグラウンド
The addition of content negotiation to the web infrastructure has been considered important since the early days of the web. Among the expected benefits of a sufficiently powerful system for content negotiation are
ウェブの初期以来ウェブインフラストラクチャとの満足している交渉の追加は重要であると考えられています。 予想の中では、満足している交渉の十分強力なシステムの利益はそうです。
* smooth deployment of new data formats and markup tags will
allow graceful evolution of the web
* 新しいデータ形式とマーク付けタグの滑らかな展開はウェブの優雅な発展を許容するでしょう。
* eliminating the need to choose between a `state of the art
multimedia homepage' and one which can be viewed by all web users
* '最先端のマルチメディアホームページ'を選ぶ必要性とすべてのウェブユーザーが見ることができるものを排除します。
* enabling good service to a wider range of browsing
platforms (from low-end PDA's to high-end VR setups)
* より広い範囲のブラウジングプラットホームに対する良いサービスを可能にします。(PDAのローエンドものからハイエンドVRセットアップまでの)
Holtman & Mutz Experimental [Page 4] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[4ページ]RFC2295
* eliminating error-prone and cache-unfriendly
User-Agent based negotiation
* 誤り傾向があってキャッシュ無愛想なUser-エージェントを排除すると、交渉は基づきました。
* enabling construction of sites without `click here for the X
version' links
* 'Xバージョンのためのここのクリック'なしでサイトの工事を可能にするのはリンクされます。
* internationalization, and the ability to offer multi-lingual
content without a bias towards one language.
* 国際化、および偏見なしで1つの言語に向かって多言語内容を提供する能力。
2 Terminology
2 用語
The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119 [4].
“MUST"という単語、「必須NOT」、“SHOULD"、「」 「5月」はRFC2119[4]で説明されるように本書では解釈されることになっているべきです。
This specification uses the term `header' as an abbreviation for for `header field in a request or response message'.
この仕様は'要求か応答メッセージにおけるヘッダーフィールド'に'ヘッダー'という略語としての用語を使用します。
2.1 Terms from HTTP/1.1
2.1 HTTP/1.1からの用語
This specification mostly uses the terminology of the HTTP/1.1 specification [1]. For the convenience of the reader, this section reproduces some key terminology definition from [1].
この仕様はHTTP/1.1仕様[1]の用語をほとんど使用します。 読者の都合のために、このセクションは[1]から何らかの主要な用語定義を再生させます。
request
An HTTP request message.
An HTTP要求メッセージを要求してください。
response
An HTTP response message.
応答An HTTP応答メッセージ。
resource
A network data object or service that can be identified by a URI.
Resources may be available in multiple representations (e.g.
multiple languages, data formats, size, resolutions) or vary in
other ways.
リソースAネットワークデータ・オブジェクトかURIで特定できるサービス。 リソースは、複数の表現(例えば、複数の言語、データ形式、サイズ、解決)で利用可能であるか、または他の方法で異なるかもしれません。
content negotiation
The mechanism for selecting the appropriate representation when
servicing a request.
aを修理するときの適切な表現を選択するためのメカニズムが要求する交渉を満足させてください。
client
A program that establishes connections for the purpose of sending
requests.
要求を送る目的のために関係を樹立するクライアントAプログラム。
user agent
The client which initiates a request. These are often browsers,
editors, spiders (web-traversing robots), or other end user tools.
ユーザエージェント、要求を開始するクライアント。 これらは、しばしばブラウザ、エディタ、クモ(ウェブを横断するロボット)、または他のエンドユーザツールです。
Holtman & Mutz Experimental [Page 5] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[5ページ]RFC2295
server
An application program that accepts connections in order to service
requests by sending back responses. Any given program may be
capable of being both a client and a server; our use of these terms
refers only to the role being performed by the program for a
particular connection, rather than to the program's capabilities in
general. Likewise, any server may act as an origin server, proxy,
gateway, or tunnel, switching behavior based on the nature of each
request.
応答を返送することによって要求を修理するために接続を受け入れるサーバAnアプリケーション・プログラム。 どんな与えられたプログラムもクライアントとサーバの両方であることができるかもしれません。 私たちのこれらの用語の使用は一般に、プログラムの能力にというよりむしろ特定の接続のためのプログラムで実行される役割だけについて言及します。 同様に、どんなサーバも発生源サーバ、プロキシ、ゲートウェイ、またはトンネルとして務めるかもしれません、それぞれの要求の本質に基づく振舞いを切り換えて。
origin server
The server on which a given resource resides or is to be created.
発生源サーバ、住んでいるか、または作成される与えられたリソースがことであるサーバ。
proxy
An intermediary program which acts as both a server and a client
for the purpose of making requests on behalf of other clients.
Requests are serviced internally or by passing them on, with
possible translation, to other servers. A proxy must implement
both the client and server requirements of this specification.
他のクライアントを代表して要求をする目的のためのサーバとクライアントの両方として作動するプロキシAn仲介者プログラム。 要求は、内部的か可能な翻訳で他のサーバにそれらを伝えることによって、修理されます。 プロキシは、両方がこの仕様のクライアントとサーバ要件であると実装しなければなりません。
age
The age of a response is the time since it was sent by, or
successfully validated with, the origin server.
応答がそれを送って以来の時間、または首尾よく有効にされるaの時代の年をとってください、発生源サーバ。
fresh
A response is fresh if its age has not yet exceeded its freshness
lifetime.
時代がまだ新しさ生涯を超えていないなら、新鮮なA応答は新鮮です。
2.2 New terms
2.2 新しい用語
transparently negotiable resource
A resource, identified by a single URI, which has multiple
representations (variants) associated with it. When servicing a
request on its URI, it allows selection of the best representation
using the transparent content negotiation mechanism. A
transparently negotiable resource always has a variant list bound
to it, which can be represented as an Alternates header (defined in
section 8.3).
それに関連している複数の表現(異形)を持っているただ一つのURIによって特定された透過的に交渉可能なリソースAリソース。 URIに関する要求を修理するとき、それは、見え透いた満足している交渉メカニズムを使用することで最も良い表現の選択を許します。 透過的に交渉可能なリソースには、それに縛られた異形リストがいつもあります。(Alternatesヘッダー(セクション8.3で、定義される)としてそれを表すことができます)。
variant list
A list containing variant descriptions, which can be bound to a
transparently negotiable resource.
透過的に交渉可能なリソースに縛ることができる異形記述を含む異形リストAリスト。
Holtman & Mutz Experimental [Page 6] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[6ページ]RFC2295
variant description
A machine-readable description of a variant resource, usually found
in a variant list. A variant description contains the variant
resource URI and various attributes which describe properties of
the variant. Variant descriptions are defined in section 5.
通常、異形リストで見つけられた異形リソースの異形の記述のA機械可読な記述。 異形記述は異形の特性について説明する異形リソースURIと様々な属性を含んでいます。 異形記述はセクション5で定義されます。
variant resource
A resource from which a variant of a negotiable resource can be
retrieved with a normal HTTP/1.x GET request, i.e. a GET request
which does not use transparent content negotiation.
すなわち、正常なHTTP/1.x GET要求、わかりやすい満足している交渉を使用しないGET要求で交渉可能なリソースの異形を検索できる異形リソースAリソース。
neighboring variant
A variant resource is called a neighboring variant resource of some
transparently negotiable HTTP resource if the variant resource has
a HTTP URL, and if the absolute URL of the variant resource up to
its last slash equals the absolute URL of the negotiable resource
up to its last slash, where equality is determined with the URI
comparison rules in section 3.2.3 of [1]. The property of being a
neighboring variant is important because of security considerations
(section 14.2). Not all variants of a negotiable resource need to
be neighboring variants. However, access to neighboring variants
can be more highly optimized by the use of remote variant selection
algorithms (section 7) and choice responses (section 10.2).
異形リソースでHTTP URLがあって、最後のスラッシュまでの異形リソースの絶対URLが最後のスラッシュまでの平等が[1]でセクション3.2.3におけるURI比較規則に決定している交渉可能なリソースの絶対URLと等しいなら、隣接している異形A異形リソースは何らかの透過的に交渉可能なHTTPリソースの隣接している異形リソースと呼ばれます。 隣接している異形である特性はセキュリティ問題(セクション14.2)のために重要です。 交渉可能なリソースのすべての異形が、隣接している異形である必要があるというわけではありません。 しかしながら、隣接している異形へのアクセスは、よりリモート異形選択アルゴリズム(セクション7)の使用で非常に最適化されて、特選している応答であるかもしれません(セクション10.2)。
remote variant selection algorithm
A standardized algorithm by which a server can sometimes choose a
best variant on behalf of a negotiating user agent. The algorithm
typically computes whether the Accept- headers in the request
contain sufficient information to allow a choice, and if so, which
variant is the best variant. The use of a remote algorithm can
speed up the negotiation process.
リモート異形選択アルゴリズムAはサーバが交渉しているユーザエージェントを代表して時々選ぶことができる中で異形最も良いアルゴリズムを標準化しました。 要求におけるAcceptヘッダーが選択を許すことができるくらいの情報を含んでいるか否かに関係なく、アルゴリズムは通常計算されます、そして、そうだとすれば、最も良い異形はどの異形ですか? リモートアルゴリズムの使用は交渉プロセスを加速できます。
list response
A list response returns the variant list of the negotiable
resource, but no variant data. It can be generated when the server
does not want to, or is not allowed to, return a particular best
variant for the request. List responses are defined in section
10.1.
リスト応答Aリスト応答は交渉可能なリソースにもかかわらず、異形データがない異形リストを返します。 それは、サーバを生成されたくないと生成することができるか、または許容されていなくて、リターンは要求のための特定の最も良い異形です。 リスト応答はセクション10.1で定義されます。
choice response
A choice response returns a representation of the best variant for
the request, and may also return the variant list of the negotiable
resource. It can be generated when the server has sufficient
information to be able to choose the best variant on behalf the
user agent, but may only be generated if this best variant is a
neighboring variant. Choice responses are defined in section 10.2.
A特選している応答選択応答は、要求のために最も良い異形の表現を返して、また、交渉可能なリソースの異形リストを返すかもしれません。 生成されて、サーバにはいつまで十分な情報があるかが利益で最も良い異形にユーザエージェントを選ぶことができますが、この最も良い異形が隣接している異形である場合にだけ生成されるかもしれないということであるかもしれません。 特選している応答はセクション10.2で定義されます。
Holtman & Mutz Experimental [Page 7] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[7ページ]RFC2295
adhoc response
An adhoc response can be sent by an origin server as an extreme
measure, to achieve compatibility with a non-negotiating or buggy
client if this compatibility cannot be achieved by sending a list
or choice response. There are very little requirements on the
contents of an adhoc response. Adhoc responses are defined in
section 10.3.
発生源サーバで思いきった手段としてadhoc応答An adhoc応答を送ることができて、非交渉かバギーとの互換性を獲得するために、この互換性であるならリストか特選している応答を送ることによって、クライアントを達成できません。 adhoc応答のコンテンツに関する非常に小さい要件があります。 Adhoc応答はセクション10.3で定義されます。
Accept- headers
The request headers: Accept, Accept-Charset, Accept-Language, and
Accept-Features.
ヘッダーのために要求ヘッダーを受け入れてください: 受け入れてください。Charsetを受け入れて、言語を受け入れて、特徴を受け入れます。
supports transparent content negotiation
From the viewpoint of an origin server or proxy, a user agent
supports transparent content negotiation if and only if it sends a
Negotiate header (section 8.4) which indicates such support.
そして、見え透いた内容交渉Fromがサーバかプロキシ、ユーザエージェントがわかりやすい満足している交渉をサポートする発生源の観点であるとサポートする、そのようなサポートを示すNegotiateヘッダー(セクション8.4)を送る場合にだけ。
server-side override
If a request on a transparently negotiated resource is made by a
client which supports transparent content negotiation, an origin
server is said to perform a server-side override if the server
ignores the directives in the Negotiate request header, and instead
uses a custom algorithm to choose an appropriate response. A
server-side override can sometimes be used to work around known
client bugs. It could also be used by protocol extensions on top
of transparent content negotiation.
サーバ側は透過的に交渉されたリソースに関する要求がクライアントによってされるIfをくつがえして、(わかりやすい満足している交渉をサポートします)サーバがNegotiate要求ヘッダーで指示を無視して、適切な応答を選ぶのに代わりにカスタムアルゴリズムを使用するなら、発生源サーバはサーバサイドオーバーライドを実行すると言われます。 知られているクライアントバグの周りで働くのに時々サーバサイドオーバーライドを使用できます。 また、わかりやすい満足している交渉の上でプロトコル拡大でそれを使用できるでしょう。
3 Notation
3 記法
The version of BNF used in this document is taken from [1], and many of the nonterminals used are defined in [1]. Note that the underlying charset is US-ASCII.
[1]から本書では使用されるBNFのバージョンを取ります、そして、[1]で使用される「非-端末」の多くを定義します。 基本的なcharsetが米国-ASCIIであることに注意してください。
One new BNF construct is added:
1個の新しいBNF構造物が加えられます:
1%rule
1%の規則
stands for one or more instances of "rule", separated by whitespace:
空白によって切り離された「規則」の1つ以上のインスタンスのためのスタンド:
1%rule = rule *( 1*LWS rule )
1%の規則=規則*(1*LWS規則)
This specification also introduces
また、この仕様は導入します。
number = 1*DIGIT
数は1*DIGITと等しいです。
short-float = 1*3DIGIT [ "." 0*3DIGIT ]
脆い浮遊物=1*3DIGIT[「. 」 0*3DIGIT、]
Holtman & Mutz Experimental [Page 8] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[8ページ]RFC2295
This specification uses the same conventions as in [1] (see section 1.2 of [1]) for defining the significance of each particular requirement.
この仕様は[1]のように同じコンベンションを使用します。(それぞれの特定の要件の意味を定義するためのセクション1.2の[1])を見てください。
4 Overview
4概要
This section gives an overview of transparent content negotiation. It starts with a more general discussion of negotiation as provided by HTTP.
このセクションはわかりやすい満足している交渉の概要を与えます。 それはHTTPで提供するように交渉の、より一般的な議論から始まります。
4.1 Content negotiation
4.1 満足している交渉
HTTP/1.1 allows web site authors to put multiple versions of the same information under a single resource URI. Each of these versions is called a `variant'. For example, a resource http://x.org/paper could bind to three different variants of a paper:
HTTP/1.1で、ウェブサイトの作者は同じ情報の複数のバージョンをただ一つのリソースURIの下に置くことができます。 それぞれのこれらのバージョンは'異形'と呼ばれます。 例えば、リソース http://x.org/paper は論文の3つの異なった異形まで固まることができました:
1. HTML, English
2. HTML, French
3. Postscript, English
1. HTML、英語2。 HTML、フランス語3。 追伸、英語
Content negotiation is the process by which the best variant is selected if the resource is accessed. The selection is done by matching the properties of the available variants to the capabilities of the user agent and the preferences of the user.
満足している交渉はリソースがアクセスされているなら最も良い異形が選択されるプロセスです。 ユーザエージェントの能力とユーザの好みに利用可能な異形の特性を合わせることによって、選択します。
It has always been possible under HTTP to have multiple representations available for one resource, and to return the most appropriate representation for each subsequent request. However, HTTP/1.1 is the first version of HTTP which has provisions for doing this in a cache-friendly way. These provisions include the Vary response header, entity tags, and the If-None-Match request header.
1つのリソースに利用可能な複数の表現を持って、それぞれのその後の要求の最も適切な表現を返すのはHTTPの下でいつも可能です。 しかしながら、HTTP/1.1は、キャッシュに優しい方法でこれをするための条項を持っているHTTPの最初のバージョンです。 これらの条項はVary応答ヘッダ、実体タグ、およびなにも合わせないIf要求ヘッダーを含んでいます。
4.2 HTTP/1.0 style negotiation scheme
4.2 HTTP/1.0スタイル交渉体系
The HTTP/1.0 protocol elements allow for a negotiation scheme as follows:
HTTP/1.0個のプロトコル要素が以下の交渉体系のために以下を許容します。
Server _____ proxy _____ proxy _____ user
x.org cache cache agent
サーバ_____ プロキシ_____ プロキシ_____ ユーザx.orgキャッシュキャッシュエージェント
< ----------------------------------
| GET http://x.org/paper
| Accept- headers
choose
|
---------------------------------- >
Best variant
<。---------------------------------- | http://x.org/paper を手に入れてください。| ヘッダーを受け入れてください、選ぶ。| ---------------------------------- >の最も良い異形
Holtman & Mutz Experimental [Page 9] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[9ページ]RFC2295
When the resource is accessed, the user agent sends (along with its request) various Accept- headers which express the user agent capabilities and the user preferences. Then the origin server uses these Accept- headers to choose the best variant, which is returned in the response.
リソースがアクセスされているとき、ユーザエージェントはユーザエージェント能力とユーザー選択を言い表す様々なAcceptヘッダーを送ります(要求と共に)。 そして、発生源サーバは、応答で返される中で最も良い異形を選ぶのにこれらのAcceptヘッダーを使用します。
The biggest problem with this scheme is that it does not scale well. For all but the most minimal user agents, Accept- headers expressing all capabilities and preferences would be very large, and sending them in every request would be hugely inefficient, in particular because only a small fraction of the resources on the web have multiple variants.
この体系に関する最も大きい問題はよく比例しないということです。 ほとんど最も最小量のユーザエージェントには、すべての能力と好みを言い表すAcceptヘッダーは非常に大きいでしょう、そして、あらゆる要求でそれらを送るのは非常に効率が悪いでしょう、ウェブに関するリソースのわずかな部分だけには複数の異形が特にあるので。
4.3 Transparent content negotiation scheme
4.3 透明な満足している交渉体系
The transparent content negotiation scheme eliminates the need to send huge Accept- headers, and nevertheless allows for a selection process that always yields either the best variant, or an error message indicating that user agent is not capable of displaying any of the available variants.
透明な満足している交渉体系は、巨大なAcceptヘッダーを送る必要性を排除して、それにもかかわらず、いつもユーザエージェントが利用可能な異形のどれかを表示できないのを示す最も良い異形かエラーメッセージのどちらかをもたらす選択プロセスを考慮します。
Under the transparent content negotiation scheme, the server sends a list with the available variants and their properties to the user agent. An example of a list with three variants is
透明な満足している交渉体系の下では、サーバは利用可能な異形と彼らの特性があるリストをユーザエージェントに送ります。 3つの異形があるリストに関する例はそうです。
{"paper.1" 0.9 {type text/html} {language en}},
{"paper.2" 0.7 {type text/html} {language fr}},
{"paper.3" 1.0 {type application/postscript} {language en}}
「紙の0.1インチ0.9タイプテキスト/html言語アン、「紙の0.2インチ0.7タイプテキスト/html言語fr、」「紙の0.3インチ1.0タイプアプリケーション/追伸言語アン、」
The syntax and semantics of the variant descriptions in this list are covered in section 5. When the list is received, the user agent can choose the best variant and retrieve it. Graphically, the communication can be represented as follows:
このリストにおける異形記述の構文と意味論はセクション5で含まれています。 リストが受信されているとき、ユーザエージェントは、最も良い異形を選んで、それを検索できます。 グラフィカルに、以下の通りコミュニケーションを表すことができます:
Holtman & Mutz Experimental [Page 10] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[10ページ]RFC2295
Server _____ proxy _____ proxy _____ user
x.org cache cache agent
サーバ_____ プロキシ_____ プロキシ_____ ユーザx.orgキャッシュキャッシュエージェント
< ----------------------------------
| GET http://x.org/paper
|
----------------------------------- > [list response]
return of list |
choose
|
< ----------------------------------
| GET http://x.org/paper.1
|
---------------------------------- > [normal response]
return of paper.1
<。---------------------------------- | http://x.org/paper を手に入れてください。| ----------------------------------- リストの>[リスト応答]復帰| 選んでください。| <。---------------------------------- | http://x.org/paper.1 を手に入れてください。| ---------------------------------- 紙.1の>[通常の応答]復帰
The first response returning the list of variants is called a `list response'. The second response is a normal HTTP response: it does not contain special content negotiation related information. Only the user agent needs to know that the second request actually retrieves a variant. For the other parties in the communication, the second transaction is indistinguishable from a normal HTTP transaction.
異形のリストを返す最初の応答は'リスト応答'と呼ばれます。 2番目の応答は通常のHTTP応答です: それは特別な満足している交渉関連情報を含んでいません。 ユーザエージェントだけが、2番目の要求が実際に異形を検索するのを知る必要があります。 コミュニケーションの相手にとって、2番目のトランザクションは正常なHTTPトランザクションから区別がつきません。
With this scheme, information about capabilities and preferences is only used by the user agent itself. Therefore, sending such information in large Accept- headers is unnecessary. Accept- headers do have a limited use in transparent content negotiation however; the sending of small Accept- headers can often speed up the negotiation process. This is covered in section 4.4.
この体系で、能力と好みの情報はユーザエージェント自身によって使用されるだけです。 したがって、大きいAcceptヘッダーでそのような情報を送るのは不要です。 受け入れてください。しかしながら、ヘッダーには、わかりやすい内容交渉における限られた使用があります。 小さいAcceptヘッダーの発信はしばしば交渉プロセスを加速できます。 これはセクション4.4でカバーされています。
List responses are covered in section 10.1. As an example, the list response in the above picture could be:
リスト応答はセクション10.1でカバーされています。 例として、上の画像におけるリスト応答は以下の通りであるかもしれません。
HTTP/1.1 300 Multiple Choices
Date: Tue, 11 Jun 1996 20:02:21 GMT
TCN: list
Alternates: {"paper.1" 0.9 {type text/html} {language en}},
{"paper.2" 0.7 {type text/html} {language fr}},
{"paper.3" 1.0 {type application/postscript}
{language en}}
Vary: negotiate, accept, accept-language
ETag: "blah;1234"
Cache-control: max-age=86400
Content-Type: text/html
Content-Length: 227
<h2>Multiple Choices:</h2>
<ul>
HTTP/1.1 300の選択式日付: グリニッジ標準時1996年6月11日火曜日20時2分21秒TCN: Alternatesを記載してください: 「紙の0.1インチ0.9タイプテキスト/html言語アン、「紙の0.2インチ0.7タイプテキスト/html言語fr、「紙の0.3インチ1.0タイプアプリケーション/追伸言語アン、異なります:、」 交渉してくださいといって、言語を受け入れて受け入れてください、ETag: 「たわごと; 1234」はキャッシュで制御されます: =86400コンテントタイプの最大に年をとってください: html Contentテキスト/長さ: 227の<h2>選択式: </h2><ul>。
Holtman & Mutz Experimental [Page 11] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[11ページ]RFC2295
<li><a href=paper.1>HTML, English version</a>
<li><a href=paper.2>HTML, French version</a>
<li><a href=paper.3>Postscript, English version</a>
</ul>
<li><a hrefは紙.1の>HTMLと等しく、英語版</a><li><a hrefは紙.2の>HTMLと等しく、フランスのバージョン</a><li><a hrefは紙.3の>Postscript、英語版</a></ul>と等しいです。
The Alternates header in the response contains the variant list. The Vary header is included to ensure correct caching by plain HTTP/1.1 caches (see section 10.6). The ETag header allows the response to be revalidated by caches, the Cache-Control header controls this revalidation. The HTML entity included in the response allows the user to select the best variant by hand if desired.
応答におけるAlternatesヘッダーは異形リストを含んでいます。 Varyヘッダーは、明瞭なHTTP/1.1のキャッシュによる正しいキャッシュを確実にするために含まれています(セクション10.6を見てください)。 ETagヘッダーは、応答がキャッシュによって再有効にされるのを許容して、Cache-コントロールヘッダーはこの再合法化を制御します。 応答にHTML実体を含んでいるのに、望まれているなら、ユーザは手で最も良い異形を選択できます。
4.4 Optimizing the negotiation process
4.4 交渉プロセスを最適化すること。
The basic transparent negotiation scheme involves two HTTP transactions: one to retrieve the list, and a second one to retrieve the chosen variant. There are however several ways to `cut corners' in the data flow path of the basic scheme.
基本的な透明な交渉体系は2つのHTTPトランザクションにかかわります: リストを検索する1、選ばれた異形を検索する2番目の1つ。 しかしながら、'手を抜く'いくつかの方法が基本的な体系のデータ流路にあります。
First, caching proxies can cache both variant lists and variants. Such caching can reduce the communication overhead, as shown in the following example:
まず最初に、プロキシをキャッシュすると、異形リストと異形の両方をキャッシュできます。 そのようなキャッシュは以下の例に示されるようにコミュニケーションオーバーヘッドを下げることができます:
Server _____ proxy _____ proxy __________ user
x.org cache cache agent
サーバ_____ プロキシ_____ プロキシ__________ ユーザx.orgキャッシュキャッシュエージェント
< --------------
| GET ../paper
|
has the list
in cache
|
------------- > [list response]
list |
|
choose
|
< --------------------------
| GET ../paper.1
|
has the variant
in cache
|
-------------------------- > [normal response]
return of paper.1
<。-------------- | 得ます。/紙| キャッシュでリストを持っています。| ------------- >[リスト応答]リスト| | 選んでください。| <。-------------------------- | 得ます。/紙.1| キャッシュで異形を持っています。| -------------------------- 紙.1の>[通常の応答]復帰
Holtman & Mutz Experimental [Page 12] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[12ページ]RFC2295
Second, the user agent can send small Accept- headers, which may contain enough information to allow the server to choose the best variant and return it directly.
2番目に、ユーザエージェントは小さいAcceptヘッダーを送ることができます。(ヘッダーはサーバが最も良い異形を選んで、直接それを返すのを許容できるくらいの情報を含むかもしれません)。
Server _____ proxy _____ proxy _____ user
x.org cache cache agent
サーバ_____ プロキシ_____ プロキシ_____ ユーザx.orgキャッシュキャッシュエージェント
< ----------------------------------
| GET http://x.org/paper
| small Accept- headers
|
able to choose on
behalf of user agent
|
---------------------------------- > [choice response]
return of paper.1 and list
<。---------------------------------- | http://x.org/paper を手に入れてください。| 小さいAcceptヘッダー| ユーザエージェントを代表して選ぶことができます。| ---------------------------------- 紙.1とリストの>[特選している応答]復帰
This choosing based on small Accept- headers is done with a `remote variant selection algorithm'. Such an algorithm takes the variant list and the Accept- headers as input. It then computes whether the Accept- headers contain sufficient information to choose on behalf of the user agent, and if so, which variant is the best variant. If the best variant is a neighboring variant, it may be returned, together with the variant list, in a choice response.
'リモート異形選択アルゴリズム'で小さいAcceptヘッダーに基づくこの選ぶことをします。 そのようなアルゴリズムは入力されるように異形リストとAcceptヘッダーを連れて行きます。 Acceptヘッダーがユーザエージェントを代表して選ぶ十分な情報を含んでいるか否かに関係なく、それは次に、計算されます、そして、そうだとすれば、最も良い異形はどの異形ですか? 最も良い異形が隣接している異形であるなら、それを返すかもしれません、異形リストと共に、特選している応答で。
A server may only choose on behalf of a user agent supporting transparent content negotiation if the user agent explicitly allows the use of a particular remote variant selection algorithm in the Negotiate request header. User agents with sophisticated internal variant selection algorithms may want to disallow a remote choice, or may want to allow it only when retrieving inline images. If the local algorithm of the user agent is superior in only some difficult areas of negotiation, it is possible to enable the remote algorithm for the easy areas only. More information about the use of a remote variant selection algorithm can be found in [3].
サーバは、わかりやすい満足している交渉をサポートするユーザエージェントを代表してユーザエージェントが明らかにNegotiate要求ヘッダーにおける特定のリモート異形選択アルゴリズムの使用を許すかどうかを選ぶだけであるかもしれません。 インライン画像を検索するときだけ、高度な内部の異形選択アルゴリズムをもっているユーザエージェントは、リモート選択を禁じたいか、またはそれを許したがっているかもしれません。 ユーザエージェントのローカルのアルゴリズムが交渉のいくつかだけの難しい領域で優れているなら、リモートアルゴリズムを簡単な領域だけに可能にするのは可能です。 [3]でリモート異形選択アルゴリズムの使用に関する詳しい情報を見つけることができます。
Choice responses are covered in section 10.2. For example, the choice response in the above picture could be:
特選している応答はセクション10.2でカバーされています。 例えば、上の画像における特選している応答は以下の通りであるかもしれません。
HTTP/1.1 200 OK
Date: Tue, 11 Jun 1996 20:05:31 GMT
TCN: choice
Content-Type: text/html
Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT
Content-Length: 5327
Cache-control: max-age=604800
Content-Location: paper.1
Alternates: {"paper.1" 0.9 {type text/html} {language en}},
HTTP/1.1 200OK日付: グリニッジ標準時1996年6月11日火曜日20時5分31秒TCN: 特選しているコンテントタイプ: htmlテキスト/最終更新日: グリニッジ標準時1996年6月10日月曜日10時1分14秒のコンテンツの長さ: 5327年のキャッシュ制御: 最大時代は604800Content-位置と等しいです: 紙.1のAlternates: 「紙の0.1インチ0.9タイプテキスト/html言語アン、」
Holtman & Mutz Experimental [Page 13] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[13ページ]RFC2295
{"paper.2" 0.7 {type text/html} {language fr}},
{"paper.3" 1.0 {type application/postscript}
{language en}}
Etag: "gonkyyyy;1234"
Vary: negotiate, accept, accept-language
Expires: Thu, 01 Jan 1980 00:00:00 GMT
「紙の0.2インチ0.7タイプテキスト/html言語fr、「紙の0.3インチ1.0タイプアプリケーション/追伸言語アン、Etag:、」 「gonkyyyy; 1234はインチ異なります: 交渉してくださいといって、言語を受け入れて受け入れてください、Expires: グリニッジ標準時1980年1月1日木曜日0時0分0秒
<title>A paper about ....
<、>Aを紙と題をつけます。
Finally, the above two kinds of optimization can be combined; a caching proxy which has the list will sometimes be able to choose on behalf of the user agent. This could lead to the following communication pattern:
最終的に、上の2種類の最適化を結合できます。 リストを持っているプロキシが時々ユーザエージェントを代表して選ぶことができるキャッシュ。 これは以下のコミュニケーションパターンに通じるかもしれません:
Server _____ proxy _____ proxy __________ user
x.org cache cache agent
サーバ_____ プロキシ_____ プロキシ__________ ユーザx.orgキャッシュキャッシュエージェント
< ---------------
| GET ../paper
| small Accept
|
able to choose
on behalf
|
< ----------
| GET ../paper.1
|
---------- > [normal response]
paper.1 |
---------------- > [choice response]
paper.1 and list
<。--------------- | 得ます。/紙| 小さいAccept| 利益として選ぶことができます。| <。---------- | 得ます。/紙.1| ---------- >[通常の応答]紙.1| ---------------- >[特選している応答]紙.1とリスト
Note that this cutting of corners not only saves bandwidth, it also eliminates delays due to packet round trip times, and reduces the load on the origin server.
角のこの切断が帯域幅を保存するだけではないというメモ、それはまた、パケット周遊旅行回数のため遅れをなくして、発生源サーバで負荷を減少させます。
4.5 Downwards compatibility with non-negotiating user agents
4.5、下向きである、非交渉しているユーザエージェントとの互換性
To handle requests from user agents which do not support transparent content negotiation, this specification allows the origin server to revert to a HTTP/1.0 style negotiation scheme. The specification of heuristics for such schemes is beyond the scope of this document.
ユーザエージェントからのわかりやすい満足している交渉をサポートしない要求を扱うために、この仕様で、発生源サーバはHTTP/1.0スタイル交渉体系に戻ります。 そのような体系のための発見的教授法の仕様はこのドキュメントの範囲を超えています。
Holtman & Mutz Experimental [Page 14] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[14ページ]RFC2295
4.6 Retrieving a variant by hand
4.6 手で異形を検索すること。
It is always possible for a user agent to retrieve the variant list which is bound to a negotiable resource. The user agent can use this list to make available a menu of all variants and their characteristics to the user. Such a menu allows the user to randomly browse other variants, and makes it possible to manually correct any sub-optimal choice made by the automatic negotiation process.
ユーザエージェントが交渉可能なリソースに縛られる異形リストを検索するのは、いつも可能です。 ユーザエージェントは、ユーザへのすべての異形とそれらの特性に関するメニューを利用可能にするのにこのリストを使用できます。 そのようなメニューで、ユーザが手当たりしだいに他の異形をブラウズするのを許容して、手動で自動交渉プロセスによってされたどんなサブ最適選択も修正するのは可能になります。
4.7 Dimensions of negotiation
4.7 交渉の次元
Transparent content negotiation defines four dimensions of negotiation:
わかりやすい満足している交渉は交渉の4次元を定義します:
1. Media type (MIME type)
2. Charset
3. Language
4. Features
1. メディアは(MIMEの種類)2をタイプします。 Charset3。 言語4。 特徴
The first three dimensions have traditionally been present in HTTP. The fourth dimension is added by this specification. Additional dimensions, beyond the four mentioned above, could be added by future specifications.
最初の三次元はHTTPで伝統的に存在しています。 第四次元はこの仕様で加えられます。 将来の仕様で前記のように4を超えて追加寸法を加えることができるでしょう。
Negotiation on the content encoding of a response (gzipped, compressed, etc.) is left outside of the realm of transparent negotiation. See section 10.8 for more information.
応答(gzippedされて、圧縮されたなど)の満足しているコード化の交渉はわかりやすい交渉の分野の外から外されます。 詳しい情報に関してセクション10.8を見てください。
4.8 Feature negotiation
4.8 特徴交渉
Feature negotiation intends to provide for all areas of negotiation not covered by the type, charset, and language dimensions. Examples are negotiation on
交渉がタイプ、charset、および言語の重要性でカバーされなかった交渉のすべての領域に備えるつもりである特徴。 例、交渉は進行中です。
* HTML extensions
* Extensions of other media types
* Color capabilities of the user agent
* Screen size
* Output medium (screen, paper, ...)
* Preference for speed vs. preference for graphical detail
* タイプ*がユーザエージェント*画面サイズ*出力媒体(スクリーン、紙)の能力に着色する他のメディアのHTML拡大*拡大 * 速度のための好み対グラフィカルな詳細のための好み
The feature negotiation framework (section 6) is the principal means by which transparent negotiation offers extensibility; a new dimension of negotiation (really a sub-dimension of the feature dimension) can be added without the need for a new standards effort by the simple registration of a `feature tag'.
特徴交渉フレームワーク(セクション6)はわかりやすい交渉が伸展性を提供する主要な手段です。 新しい規格取り組みの必要性なしで'特徴タグ'の簡単な登録で交渉(本当に特徴寸法のサブ次元)の新しい次元を加えることができます。
Holtman & Mutz Experimental [Page 15] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[15ページ]RFC2295
4.9 Length of variant lists
4.9 異形リストの長さ
As a general rule, variant lists should be short: it is expected that a typical transparently negotiable resource will have 2 to 10 variants, depending on its purpose. Variant lists should be short for a number of reasons:
概して、異形リストは短いはずです: 目的によって、典型的な透過的に交渉可能なリソースには2〜10の異形があると予想されます。 異形リストは様々な意味で短いはずです:
1. The user must be able to pick a variant by hand to correct a
bad automatic choice, and this is more difficult with a long
variant list.
1. ユーザは悪い自動選択を修正するために手で異形を選ぶことができなければなりません、そして、これは長い異形リストによって、より難しいです。
2. A large number of variants will decrease the efficiency of
internet proxy caches.
2. 多くの異形がインターネットプロキシキャッシュの効率を減少させるでしょう。
3. Long variant lists will make some transparently negotiated
responses longer.
3. 長い異形リストで、いくつかの透過的に交渉された応答が、より長くなるでしょう。
In general, it is not desirable to create a transparently negotiable resource with hundreds of variants in order to fine-tune the graphical presentation of a resource. Any graphical fine-tuning should be done, as much as possible, by using constructs which act at the user agent side, for example
一般に、何百もの異形で透過的に交渉可能なリソースを作成するのは、リソースのグラフ式表現について微調整するために望ましくはありません。 できるだけ例えばユーザエージェント側で行動する構造物を使用することによって、どんなグラフィカルな微調整もするべきです。
<center><img src=titlebanner.gif width=100%
alt="MegaBozo Corp"></center>
<のセンター><img src=titlebanner.gif幅が100%のalt=と等しい、「MegaBozo Corp「></センター>」
In order to promote user agent side fine tuning, which is more scalable than fine tuning over the network, user agents which implement a scripting language for content rendering are encouraged to make the availability of this language visible for transparent content negotiation, and to allow rendering scripts to access the capabilities and preferences data used for content negotiation, as far as privacy considerations permit this.
ユーザを昇進させるように、エージェント側はわかりやすい満足している交渉、レンダリングするのを許容するのにおいて目に見えるこの言語の有用性が能力にアクセスするために作る満足しているレンダリングのためのスクリプト言語が奨励されるどの道具に原稿を書くか、そして、好みのデータが満足している交渉に使用したユーザエージェントにチューニングに罰金を課します、プライバシー問題がこれを可能にする限り。(チューニングはネットワークの上の微調整よりスケーラブルです)。
4.10 Relation with other negotiation schemes
4.10 他の交渉体系との関係
The HTTP/1.x protocol suite allows for many different negotiation mechanisms. Transparent content negotiation specializes in scalable, interoperable negotiation of content representations at the HTTP level. It is intended that transparent negotiation can co-exist with other negotiation schemes, both open and proprietary, which cover different application domains or work at different points in the author-to-user chain. Ultimately, it will be up to the resource author to decide which negotiation mechanism, or combination of negotiation mechanisms, is most appropriate for the task at hand.
HTTP/1.xプロトコル群は多くの異なった交渉メカニズムを考慮します。わかりやすい満足している交渉はHTTPレベルで満足している表現のスケーラブルで、共同利用できる交渉を専門に扱います。 わかりやすい交渉が開いているものと作者からユーザへのチェーンで異なったアプリケーションドメインをカバーしているか、または異なったポイントでうまくいく他の同様に独占である交渉体系と共存できることを意図します。 結局、どの交渉メカニズムについて決めるかが、リソース作者次第であるか手元のタスクに、交渉メカニズムの組み合わせは最も適切です。
Holtman & Mutz Experimental [Page 16] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[16ページ]RFC2295
5 Variant descriptions
5 異形記述
5.1 Syntax
5.1構文
A variant can be described in a machine-readable way with a variant description.
異形記述がある機械可読な方法で異形について説明できます。
variant-description =
"{" <"> URI <"> source-quality *variant-attribute"}"
異形記述が等しい、「「<、「>URI<「>ソース品質*異形属性」、」、」
source-quality = qvalue
ソース品質はqvalueと等しいです。
variant-attribute = "{" "type" media-type "}"
| "{" "charset" charset "}"
| "{" "language" 1#language-tag "}"
| "{" "length" 1*DIGIT "}"
| "{" "features" feature-list "}"
| "{" "description"
quoted-string [ language-tag ] "}"
| extension-attribute
異形属性=「「「タイプ」メディアタイプ」」| 「「"charset"charset」」| 「「「言語」1#言語タグ」」| 「「「長さ」1*ケタ」」| 「「「特徴」特徴リスト」」| 「「「記述」引用文字列[言語タグ]」」| 拡大属性
extension-attribute = "{" extension-name extension-value "}"
extension-name = token
extension-value = *( token | quoted-string | LWS
| extension-specials )
拡大属性=「「拡大名の拡大価値」」拡大名=トークン拡大価値は*と等しいです。(トークン|引用文字列|LWS| 拡大スペシャル)
extension-specials =
<any element of tspecials except <"> and "}">
そして、拡大スペシャルが<以外のtspecialsのどんな要素にも<と等しい、「>、」、">"
The feature-list syntax is defined in section 6.4.
特徴リスト構文はセクション6.4で定義されます。
Examples are
例はそうです。
{"paper.2" 0.7 {type text/html} {language fr}}
「紙の0.2インチ0.7タイプテキスト/html言語fr、」
{"paper.5" 0.9 {type text/html} {features tables}}
「紙の0.5インチ0.9タイプテキスト/htmlがテーブルを特集する、」
{"paper.1" 0.001}
「紙の0.1インチ0.001、」
The various attributes which can be present in a variant description are covered in the subsections below. Each attribute may appear only once in a variant description.
異形記述で存在する場合がある様々な属性は以下の小区分でカバーされています。 各属性は異形記述に一度だけ現れるかもしれません。
5.2 URI
5.2 ユリ
The URI attribute gives the URI of the resource from which the variant can be retrieved with a GET request. It can be absolute or relative to the Request-URI. The variant resource may vary (on the
URI属性はGET要求で異形を検索できるリソースのURIを与えます。 それは、絶対である、またはRequest-URIに比例してそうすることができます。 異形リソースが異なるかもしれない、(オン
Holtman & Mutz Experimental [Page 17] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[17ページ]RFC2295
Cookie request header, for example), but MUST NOT engage in transparent content negotiation itself.
例えば、クッキー要求ヘッダー、)、わかりやすい満足している交渉自体に従事してはいけません。
5.3 Source-quality
5.3 ソース品質
The source-quality attribute gives the quality of the variant, as a representation of the negotiable resource, when this variant is rendered with a perfect rendering engine on the best possible output medium.
ソース品質属性は異形の品質を与えます、交渉可能なリソースの表現として、可能な限り良い出力媒体の上に完全なレンダリングエンジンがある状態でこの異形がレンダリングされるとき。
If the source-quality is less than 1, it often expresses a quality degradation caused by a lossy conversion to a particular data format. For example, a picture originally in JPEG form would have a lower source quality when translated to the XBM format, and a much lower source quality when translated to an ASCII-art variant. Note however, that degradation is a function of the source; an original piece of ASCII-art may degrade in quality if it is captured in JPEG form.
ソース品質が1未満であるなら、それはしばしば特定のデータの形式への損失性変換で引き起こされた品質劣化を言い表します。 例えば、ASCII-芸術異形に翻訳される上質のXBM形式、およびはるかに低いソースに翻訳されると、元々JPEGフォームの画像には下側のソース品質があるでしょう。 しかしながら、その退行がソースの機能であることに注意してください。 それがJPEGフォームでキャプチャされるなら、オリジナルのASCII-芸術は品質で下がるかもしれません。
The source-quality could also represent a level of quality caused by skill of language translation, or ability of the used media type to capture the intended artistic expression.
また、ソース品質は言語翻訳の技術、または意図している芸術的表現を得る中古のメディアタイプの能力によって引き起こされた品質のレベルを表すかもしれません。
Servers should use the following table a guide when assigning source quality values:
上質の値をソースに割り当てるとき、サーバは以下のテーブルaガイドを使用するべきです:
1.000 perfect representation
0.900 threshold of noticeable loss of quality
0.800 noticeable, but acceptable quality reduction
0.500 barely acceptable quality
0.300 severely degraded quality
0.000 completely degraded quality
1.000が表現を完成させる、0.900敷居、上質の0.800めぼしい、しかし、許容できる上質の減少0.500のめぼしい損失では、ほとんど許容できない上質の0.300は厳しく上質の0.000完全に降格している品質を下げました。
The same table can be used by local variant selection algorithms (see appendix 19) when assigning degradation factors for different content rendering mechanisms. Note that most meaningful values in this table are close to 1. This is due to the fact that quality factors are generally combined by multiplying them, not by adding them.
メカニズムを表す異なった内容のための退行要素を割り当てるとき、ローカルの異形選択アルゴリズム(付録19を見る)で同じテーブルを使用できます。このテーブルのほとんどの重要な値がおよそ1であることに注意してください。 これは一般に、線質係数がそれらを加えることによって結合されるのではなく、それらを掛けることによって結合されるという事実のためです。
When assigning source-quality values, servers should not account for the size of the variant and its impact on transmission and rendering delays; the size of the variant should be stated in the length attribute and any size-dependent calculations should be done by the variant selection algorithm. Any constant rendering delay for a particular media type (for example due to the startup time of a helper application) should be accounted for by the user agent, when assigning a quality factor to that media type.
ソース品質値を割り当てるとき、サーバはトランスミッションとレンダリング遅れで異形とその影響のサイズを説明するべきではありません。 長さ属性で異形のサイズを述べるべきです、そして、異形選択アルゴリズムでどんなサイズ依存する計算もするべきです。 そのメディアタイプに線質係数を割り当てるとき、特定のメディアタイプ(例えば、支援アプリケーションの始動時間による)のためのどんな一定のレンダリング遅れもユーザエージェントによって説明されるべきです。
Holtman & Mutz Experimental [Page 18] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[18ページ]RFC2295
5.4 Type, charset, language, and length
5.4 タイプ、charset、言語、および長さ
The type attribute of a variant description carries the same information as its Content-Type response header counterpart defined in [1], except for any charset information, which MUST be carried in the charset attribute. For, example, the header
異形記述のタイプ属性は[1]で定義されたコンテントタイプ応答ヘッダ対応者と同じ情報を運びます、どんなcharset情報を除いても。(charset属性でそれを運ばなければなりません)。 例、ヘッダー
Content-Type: text/html; charset=ISO-8859-4
コンテントタイプ: テキスト/html。 charset=ISO-8859-4
has the counterpart attributes
対応者属性を持っています。
{type text/html} {charset ISO-8859-4}
テキスト/htmlをタイプしてください。charset ISO-8859-4
The language and length attributes carry the same information as their Content-* response header counterparts in [1]. The length attribute, if present, MUST thus reflect the length of the variant alone, and not the total size of the variant and any objects inlined or embedded by the variant.
言語と長さ属性は[1]で彼らのContent-*応答ヘッダ対応者と同じ情報を運びます。 その結果、存在しているなら、長さ属性は異形によって不裏打ちされたか、または埋め込まれた異形とどんなオブジェクトの総サイズではなく、異形の長さだけも反映しなければなりません。
Though all of these attributes are optional, it is often desirable to include as many attributes as possible, as this will increase the quality of the negotiation process.
これらの属性のすべてが任意ですが、できるだけ多くの属性を含んでいるのはしばしば望ましいです、これが交渉プロセスの品質を増強するのに従って。
Note: A server is not required to maintain a one-to-one
correspondence between the attributes in the variant description
and the Content-* headers in the variant response. For example,
if the variant description contains a language attribute, the
response does not necessarily have to contain a Content-Language
header. If a Content-Language header is present, it does not have
to contain an exact copy of the information in the language
attribute.
以下に注意してください。 サーバは、異形応答で異形記述における属性とContent-*ヘッダーとの1〜1つの通信を維持するのに必要ではありません。 例えば、異形記述が言語属性を含んでいるなら、応答は必ずContent-言語ヘッダーを含む必要はありません。 Content-言語ヘッダーが出席しているなら、それは言語属性における情報の正確なコピーを含む必要はありません。
5.5 Features
5.5 特徴
The features attribute specifies how the presence or absence of particular feature tags in the user agent affects the overall quality of the variant. This attribute is covered in section 6.4.
特徴属性はユーザエージェントの特定の特徴タグの存在か不在がどう異形の総合的な品質に影響するかを指定します。 この属性はセクション6.4でカバーされています。
5.6 Description
5.6 記述
The description attribute gives a textual description of the variant. It can be included if the URI and normal attributes of a variant are considered too opaque to allow interpretation by the user. If a user agent is showing a menu of available variants compiled from a variant list, and if a variant has a description attribute, the user agent SHOULD show the description attribute of the variant instead of showing the normal attributes of the variant. The description field uses the UTF-8 character encoding scheme [5], which is a superset of
記述属性は異形の原文の記述を与えます。 異形のURIと正常な属性がユーザによる解釈を許容できないくらい不透明であると考えられるなら、それを含むことができます。 ユーザエージェントが、利用可能な異形に関するメニューが異形リストからコンパイルされたのを示しているなら、異形に記述属性があるなら、ユーザエージェントSHOULDは異形の正常な属性を示していることの代わりに異形の記述属性を示しています。 記述分野はUTF-8文字符号化体系[5]を使用して、スーパーセットはどれのものですか?
Holtman & Mutz Experimental [Page 19] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[19ページ]RFC2295
US-ASCII, with ""%" HEX HEX" encoding. The optional language tag MAY be used to specify the language used in the description text.
「「%」十六進法十六進法」コード化がある米国-ASCII。 任意の言語タグは、記述テキストで使用される言語を指定するのに使用されるかもしれません。
5.7 Extension-attribute
5.7 拡大属性
The extension-attribute allows future specifications to incrementally define dimensions of negotiation which cannot be created by using the feature negotiation framework, and eases content negotiation experiments. In experimental situations, servers MUST ONLY generate extension-attributes whose names start with "x-". User agents SHOULD ignore all extension attributes they do not recognize. Proxies MUST NOT run a remote variant selection algorithm if an unknown extension attribute is present in the variant list.
拡大属性で、将来の仕様は特徴交渉フレームワークを使用することによって作成できないで、満足している交渉実験を緩和する交渉の次元を増加して定義できます。 実験状況で、サーバは名前が「x」から始まる拡大属性を生成するだけでよいです。 ユーザエージェントSHOULDは彼らが認識しないすべての拡大属性を無視します。 未知の拡大属性が異形リストに存在しているなら、プロキシはリモート異形選択アルゴリズムを実行してはいけません。
6 Feature negotiation
6 特徴交渉
This section defines the feature negotiation mechanism. Feature negotiation has been introduced in section 4.8. Appendix 19 contains examples of feature negotiation.
このセクションは特徴交渉メカニズムを定義します。 セクション4.8で特徴交渉を導入しました。 付録19は特徴交渉に関する例を含んでいます。
6.1 Feature tags
6.1 特徴タグ
A feature tag (ftag) identifies something which can be negotiated on, for example a property (feature) of a representation, a capability (feature) of a user agent, or the preference of a user for a particular type of representation. The use of feature tags need not be limited to transparent content negotiation, and not every feature tag needs to be usable in the HTTP transparent content negotiation framework.
特徴タグ(ftag)は特定のタイプの表現のために交渉できる何か、例えば、表現の特性(特徴)、ユーザエージェントの能力(特徴)、またはユーザの好みを特定します。 特徴タグの使用はわかりやすい満足している交渉に制限される必要はありません、そして、あらゆる特徴タグがHTTPの透明な満足している交渉フレームワークで使用可能である必要があるというわけではありません。
ftag = token | quoted-string
ftagはトークンと等しいです。| 引用文字列
Note: A protocol-independent system for feature tag registration
is currently being developed in the IETF. This specification does
not define any feature tags. In experimental situations, the use
of tags which start with "x." is encouraged.
以下に注意してください。 特徴タグ登録のプロトコルから独立しているシステムは現在、IETFで開発されています。 この仕様はどんな特徴タグも定義しません。 実験状況で、「x.」から始めるタグの使用は奨励されます。
Feature tags are used in feature sets (section 6.2) and in feature predicates (section 6.3). Feature predicates are in turn used in features attributes (section 6.4), which are used in variant descriptions (section 5). Variant descriptions can be transmitted in Alternates headers (section 8.3).
特徴タグは特徴セット(セクション6.2)と特徴述部(セクション6.3)で使用されます。 特徴述部は特徴属性(セクション6.4)に順番に使用されます。(属性は異形記述(セクション5)に使用されます)。 Alternatesヘッダー(セクション8.3)で異形記述を伝えることができます。
The US-ASCII charset is used for feature tags. Feature tag comparison is case-insensitive. A token tag XYZ is equal to a quoted-string tag "XYZ". Examples are
米国-ASCII charsetは特徴タグに使用されます。 特徴タグ比較は大文字と小文字を区別しないです。 トークンタグXYZはタグ"XYZ"という引用文字列と等しいです。 例はそうです。
tables, fonts, blebber, wolx, screenwidth, colordepth
テーブル、フォント、blebber、wolx、screenwidth、colordepth
Holtman & Mutz Experimental [Page 20] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[20ページ]RFC2295
An example of the use of feature tags in a variant description is:
異形記述における特徴タグの使用に関する例は以下の通りです。
{"index.html" 1.0 {type text/html} {features tables frames}}
1.0個の"index.html"タイプテキスト/html特徴テーブルフレーム
This specification follows general computing practice in that it places no restrictions on what may be called a feature. At the protocol level, this specification does not distinguish between different uses of feature tags: a tag will be processed in the same way, no matter whether it identifies a property, capability, or preference. For some tags, it may be fluid whether the tag represents a property, preference, or capability. For example, in content negotiation on web pages, a "textonly" tag would identify a capability of a text-only user agent, but the user of a graphical user agent may use this tag to specify that text-only content is preferred over graphical content.
特徴と呼ばれるかもしれないものに関する制限を全く置かないので、この仕様はコンピュータ一般習慣に続きます。 プロトコルレベルでは、この仕様は特徴タグの異なった用途を見分けません: 同様に、特性、能力、または好みを特定して、タグは処理されるでしょう。 いくつかのタグに関しては、タグが特性、好み、または能力を表すか否かに関係なく、それは流動的であるかもしれません。 例えば、ウェブページにおける満足している交渉では、"textonly"タグはテキストのみユーザエージェントの能力を特定するでしょうが、グラフィカルなユーザエージェントのユーザは、テキストのみ内容がグラフィカルな内容より好まれると指定するのにこのタグを使用するかもしれません。
6.1.1 Feature tag values
6.1.1 特徴タグ値
The definition of a feature tag may state that a feature tag can have zero, one, or more values associated with it. These values specialize the meaning of the tag. For example, a feature tag `paper' could be associated with the values `A4' and `A5'.
特徴タグの定義は、特徴タグがゼロ(それに関連している1つ以上の値)を持つことができると述べるかもしれません。 これらの値はタグの意味を専門にします。 例えば、タグ'紙'という特徴は値'A4'と'A5'に関連づけられるかもしれません。
tag-value = token | quoted-string
タグ値はトークンと等しいです。| 引用文字列
The US-ASCII charset is used for feature tag values. Equality comparison for tag values MUST be done with a case-sensitive, octet- by-octet comparison, where any ""%" HEX HEX" encodings MUST be processed as in [1]. A token value XYZ is equal to a quoted-string value "XYZ".
米国-ASCII charsetは特徴タグ値に使用されます。 [1]のようにどんな「「%」十六進法十六進法」encodingsも処理しなければならないところで八重奏による大文字と小文字を区別する八重奏比較で値をしなければならないタグのための平等比較。 トークン価値のXYZは値の"XYZ"という引用文字列と等しいです。
6.2 Feature sets
6.2 特徴セット
The feature set of a user agent is a data structure which records the capabilities of the user agent and the preferences of the user.
ユーザエージェントの特徴セットはユーザエージェントの能力とユーザの好みを記録するデータ構造です。
Feature sets are used by local variant selection algorithms (see appendix 19 for an example). A user agent can use the Accept- Features header (section 8.2) to make some of the contents of its feature set known to remote variant selection algorithms.
特徴セットはローカルの異形選択アルゴリズムで使用されます(例に関して付録19を見てください)。 ユーザエージェントは、特徴セットの何らかのコンテンツをリモート異形選択アルゴリズムに知らせるのに、Accept特徴ヘッダー(セクション8.2)を使用できます。
Structurally, a feature set is a possibly empty set, containing records of the form
構造的に、特徴セットはフォームに関する記録を含むことによると空のセットです。
( feature tag , set of feature tag values )
(特徴タグ、特徴タグ値のセット)
Holtman & Mutz Experimental [Page 21] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[21ページ]RFC2295
If a record with a feature tag is present in the set, this means that the user agent implements the corresponding capability, or that the user has expressed the corresponding preference.
特徴タグがある記録がセットで存在しているなら、これは、ユーザエージェントが対応する能力を実装するか、またはユーザが対応する好みを言い表したことを意味します。
Each record in a feature set has a, possibly empty, set of tag values. For feature tags which cannot have values associated with it, this set is always empty. For feature tags which can have zero, one, or more values associated with it, this set contains those values currently associated with the tag. If the set of a feature tag T has the value V in it, it is said that `the tag T is present with the value V'.
特徴セットがことによると空のaに設定させるタグ値のそれぞれの記録的なコネ。 それに関連している値を持つことができない特徴タグに関しては、このセットはいつも空です。 それに関連しているゼロ、1つ以上の値を持つことができる特徴タグに関しては、このセットは現在タグに関連しているそれらの値を含んでいます。 特徴タグTのセットがそれに値Vを持っているなら、'タグTは値Vについて存在しています'と言われます。
This specification does not define a standard notation for feature sets. An example of a very small feature set, in a mathematical notation, is
この仕様は特徴セットのために標準の記法を定義しません。 数学的表記で設定された非常に小さい特徴に関する例はそうです。
{ ( "frames" , { } ) ,
( "paper" , { "A4" , "A5" } )
}
(「フレーム」、)、(「紙」、「A4"、「A5"、)、」
As feature registration is expected to be an ongoing process, it is generally not possible for a user agent to know the meaning of all feature tags it can possibly encounter in a variant description. A user agent SHOULD treat all features tags unknown to it as absent from its feature set.
特徴登録が進行中の過程であると予想されるとき、一般に、ユーザエージェントがそれが異形記述で遭遇できるすべての特徴タグの意味を知るのは、可能ではありません。 すべてが特徴とするユーザエージェントSHOULDの御馳走は未知にそれに特徴セットを休んだ状態でタグ付けをします。
A user agent may change the contents of its feature set depending on the type of request, and may also update it to reflect changing conditions, for example a change in the window size. Therefore, when considering feature negotiation, one usually talks about `the feature set of the current request'.
ユーザエージェントは、要求のタイプに頼るように設定された特徴のコンテンツを変えて、また、状態を変えながら反射するためにそれをアップデートするかもしれません、例えば、ウィンドウサイズにおける変化。 したがって、特徴交渉を考えるとき、通常、人は'現在の要求の特徴セット'に関して話します。
6.3 Feature predicates
6.3 特徴述部
Feature predicates are predicates on the contents of feature sets. They appear in the features attribute of a variant description.
特徴述部は特徴セットのコンテンツに関する述部です。 彼らは異形記述の特徴属性に現れます。
fpred = [ "!" ] ftag
| ftag ( "=" | "!=" ) tag-value
| ftag "=" "[" numeric-range "]"
=[“!"]ftagをfpredしました。| 「ftag(「」 | 」 =と等しい」)タグ価値| 「[「数値範囲」の]」というftag「=」
numeric-range = [ number ] "-" [ number ]
数値範囲=[数]「-」[数]
Feature predicates are used in features attributes (section 6.4), which are used in variant descriptions (section 5). Variant descriptions can be transmitted in Alternates headers (section 8.3).
特徴述部は特徴属性(セクション6.4)に使用されます。(属性は異形記述(セクション5)に使用されます)。 Alternatesヘッダー(セクション8.3)で異形記述を伝えることができます。
Holtman & Mutz Experimental [Page 22] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[22ページ]RFC2295
Examples of feature predicates are
特徴述部に関する例はそうです。
blebber, !blebber, paper=a4, colordepth=5, blex!=54,
dpi=[300-599], colordepth=[24-]
a4、colordepth=5、blex!=54、dpi=[300-599]、colordepth blebber、blebber、紙==[24-]
Using the feature set of the current request, a user agent SHOULD compute the truth value of the different feature predicates as follows.
現在の要求の特徴セットを使用するユーザエージェントSHOULDが以下の異なった特徴述部の真理値を計算します。
ftag true if the feature is present, false otherwise
そうでなければ、本当に、特徴が現在であって、誤っているなら、ftagします。
!ftag true if the feature is absent, false otherwise
本当に、そうでなければ、特徴が欠けて、誤っているなら、ftagします。
ftag=V true if the feature is present with the value V,
false otherwise,
ftag=V、そうでなければ、特徴がそうなら、本当に、値でVを虚偽で提示してください。
ftag!=V true if the feature is not present with the value V,
false otherwise,
ftag!= そうでなければ、特徴がそうでないなら、本当に対して値でVを虚偽で提示してください。
ftag=[N-M] true if the feature is present with at least one
numeric value, while the highest value with which it
is present in the range N-M, false otherwise. If N
is missing, the lower bound is 0. If M is missing,
the upper bound is infinity.
特徴がそれが存在している最も高い値である間、少なくとも1つの数値について存在しているならftagが本当に中で等しい、[N-M]N Mに及んでください、誤る、そうでなければ。 Nがなくなるなら、下界は0です。 Mがなくなるなら、上限は無限です。
As an example, with the feature set
特徴セットがある例として
{ ( "blex" , { } ),
( "colordepth" , { "5" } ),
( "UA-media" , { "stationary" } ),
( "paper" , { "A4", "A3" } ) ,
( "x-version" , { "104", "200" } )
}
("blex"、)、("colordepth"、「5インチ、)、(「UA-メディア」で、「静止する」)である、(「紙」、「A4"、「A3"、)、(「x-バージョン」、「104」、「200」)、」
the following predicates are true:
以下の述部は本当です:
blex, colordepth=[4-], colordepth!=6, colordepth, !screenwidth, UA- media=stationary, UA-media!=screen, paper=A4, paper =!A0, colordepth=[ 4 - 6 ], x-version=[100-300], x-version=[200-300]
blexに、colordepthが等しい、[4、]、colordepth!=6、colordepth、screenwidth、UA-メディア!=スクリーン、紙=A4、UAメディア=静止していて、紙がA0と等しく、colordepthが=[4--6]であり、xバージョン=が[100-300]であり、x-バージョンは=です。[200-300]
and the following predicates are false:
そして、以下の述部は誤っています:
!blex, blebber, colordepth=6, colordepth=foo, !colordepth,
screenwidth, screenwidth=640, screenwidth!=640, x-version=99, UA-
media=screen, paper=A0, paper=a4, x-version=[100-199], wuxta
blex、blebber、colordepth=6、colordepth=foo、colordepth、screenwidth、screenwidth=640、screenwidth!=640、x-バージョン=99、[100-199]、UAメディア=スクリーン、紙=A0、紙=a4、x-バージョン=wuxta
Holtman & Mutz Experimental [Page 23] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[23ページ]RFC2295
6.4 Features attribute
6.4 特徴属性
The features attribute, for which section 5.1 defines the syntax
特徴属性。(セクション5.1はその属性のために構文を定義します)。
"{" "features" feature-list "}"
「「「特徴」特徴リスト」」
is used in a variant description to specify how the presence or absence of particular feature tags in the user agent affects the overall quality of the variant.
異形記述では、ユーザエージェントの特定の特徴タグの存在か不在がどう異形の総合的な品質に影響するかを指定するために、使用されます。
feature-list = 1%feature-list-element
特徴リストの=の1%の機能リスト要素
feature-list-element = ( fpred | fpred-bag )
[ ";" [ "+" true-improvement ]
[ "-" false-degradation ]
]
特徴リスト要素=(袋に入れてfpred|fpredしました); [「」、[「+」 本当の改良][「-」誤った退行]
fpred-bag = "[" 1%fpred "]"
「[「1%はfpredした」]」というfpredバッグ=
true-improvement = short-float
false-degradation = short-float
脆い浮遊物の誤った本当の改良=退行は脆い浮遊物と等しいです。
Features attributes are used in variant descriptions (section 5). Variant descriptions can be transmitted in Alternates headers (section 8.3).
特徴属性は異形記述(セクション5)に使用されます。 Alternatesヘッダー(セクション8.3)で異形記述を伝えることができます。
Examples are:
例は以下の通りです。
{features !textonly [blebber !wolx] colordepth=3;+0.7}
+0.7にtextonly[blebber!wolx]colordepth=3を特集します。
{features !blink;-0.5 background;+1.5 [blebber !wolx];+1.4-0.8}
特徴!明滅; -0.5バックグラウンド; +1.5[blebber!wolx]; +1.4-0.8
The default value for the true-improvement is 1. The default value for the false-degradation is 0, or 1 if a true-improvement value is given.
本当の改良のためのデフォルト値は1です。 誤った退行のためのデフォルト値は0であるか1がaであるなら与えられます本当の改良が、評価する。
A user agent SHOULD, and a remote variant selection algorithm MUST compute the quality degradation factor associated with the features attribute by multiplying all quality degradation factors of the elements of the feature-list. Note that the result can be a factor greater than 1.
ユーザエージェントSHOULD、およびリモート異形選択アルゴリズムは計算しなければなりません。特徴リストの要素のすべての品質劣化要素を掛けることによって特徴属性に関連している品質劣化要素を計算してください。 結果が要素より多くの1であるかもしれないに注意してください。
A feature list element yields its true-improvement factor if the corresponding feature predicate is true, or if at least one element of the corresponding fpred-bag is true. The element yields its false-degradation factor otherwise.
対応する特徴述部が本当であるか、または対応するfpredバッグの少なくとも1つの要素が真であるなら、特徴リスト要素は本当の改良要素をもたらします。 そうでなければ、要素は誤った退行要素をもたらします。
Holtman & Mutz Experimental [Page 24] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[24ページ]RFC2295
7 Remote variant selection algorithms
7 リモート異形選択アルゴリズム
A remote variant selection algorithm is a standardized algorithm by which a server can choose a best variant on behalf of a negotiating user agent. The use of a remote algorithm can speed up the negotiation process by eliminating a request-response round trip.
リモート異形選択アルゴリズムはサーバが交渉しているユーザエージェントを代表して選ぶことができる中で異形最も良い標準化されたアルゴリズムです。 リモートアルゴリズムの使用は、要求応答周遊旅行を排除することによって、交渉プロセスを加速できます。
A remote algorithm typically computes whether the Accept- headers in the request contain sufficient information to allow a choice, and if so, which variant is the best variant. This specification does not define any remote algorithms, but does define a mechanism to negotiate on the use of such algorithms.
要求におけるAcceptヘッダーが選択を許すことができるくらいの情報を含んでいるか否かに関係なく、リモートアルゴリズムは通常計算されます、そして、そうだとすれば、最も良い異形はどの異形ですか? この仕様は、どんなリモートアルゴリズムも定義しませんが、そのようなアルゴリズムの使用に関して交渉するためにメカニズムを定義します。
7.1 Version numbers
7.1 バージョン番号
A version numbering scheme is used to distinguish between different remote variant selection algorithms.
バージョンナンバリングスキームは、異なったリモート異形選択アルゴリズムを見分けるのに使用されます。
rvsa-version = major "." minor
「rvsa-バージョン=少佐」 」 未成年者
major = 1*4DIGIT
minor = 1*4DIGIT
少佐=1*4DIGIT小さい方の=1*4DIGIT
An algorithm with the version number X.Y, with Y>0, MUST be downwards compatible with all algorithms from X.0 up to X.Y. Downwards compatibility means that, if supplied with the same information, the newer algorithm MUST make the same choice, or a better choice, as the old algorithm. There are no compatibility requirements between algorithms with different major version numbers.
バージョン数のX.Y、Y>0があるアルゴリズムは下向きにそうであるに違いありません。X.0からのすべてのアルゴリズムと古いアルゴリズムとして、より十分特選しているX.Y.Downwards互換性手段同じ情報を提供していて、より新しいアルゴリズムが同じ選択をしなければならないかどうか、それ、またはさもなければ、aまで互換性があります。 異なったメジャーバージョン番号があるアルゴリズムの間には、互換性要件が全くありません。
8 Content negotiation status codes and headers
8 満足している交渉ステータスコードとヘッダー
This specification adds one new HTTP status code, and introduces six new HTTP headers. It also extends the semantics of an existing HTTP/1.1 header.
この仕様は、1つの新しいHTTPステータスコードを加えて、6つの新しいHTTPヘッダを紹介します。 また、それは既存のHTTP/1.1ヘッダーの意味論について敷衍しています。
8.1 506 Variant Also Negotiates
また、8.1 506異形は交渉されます。
The 506 status code indicates that the server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself, and is therefore not a proper end point in the negotiation process.
506ステータスコードは、サーバには内部の構成誤りがあるのを示します: 選ばれた異形リソースは、わかりやすい満足している交渉自体に従事するために構成されて、したがって、交渉プロセスの適切なエンドポイントではありません。
Holtman & Mutz Experimental [Page 25] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[25ページ]RFC2295
8.2 Accept-Features
8.2、特徴を受け入れます。
The Accept-Features request header can be used by a user agent to give information about the presence or absence of certain features in the feature set of the current request. Servers can use this information when running a remote variant selection algorithm.
ユーザエージェントは、現在の要求の特徴セットにおける、ある特徴の存在か欠如に関して知らせるのにAccept-特徴要求ヘッダーを使用できます。 リモート異形選択アルゴリズムを実行するとき、サーバはこの情報を使用できます。
Note: the name `Accept-Features' for this header was chosen
because of symmetry considerations with other Accept- headers,
even though the Accept-Features header will generally not contain
an exhaustive list of features which are somehow `accepted'. A
more accurate name of this header would have been `Feature-Set-
Info'.
以下に注意してください。 名前、'、特徴を受け入れる、'、このヘッダーは対称問題のために他のAcceptヘッダーと共に選ばれました、Accept-特徴ヘッダーは一般にどうにか'受け入れられる'特徴に関する完全なりストを含まないでしょうが。 このヘッダーの、より正確な名前は'特徴に設定されたインフォメーション'だったでしょう。
Accept-Features = "Accept-Features" ":"
#( feature-expr *( ";" feature-extension ) )
「特徴を受け入れている=、「特徴を受け入れる、」、」、:、」 #(特徴-expr*、(「」、;、特徴拡張子)
feature-expr = [ "!" ] ftag
| ftag ( "=" | "!=" ) tag-value
| ftag "=" "{" tag-value "}"
| "*"
特徴-exprは[“!"]ftagと等しいです。| 「ftag(「」 | 」 =と等しい」)タグ価値| ftagは「「タグ値」」と「等しいです」。| "*"
feature-extension = token [ "=" ( token | quoted-string ) ]
特徴拡張子はトークンと等しいです。[「=」(トークン| 引用文字列)]
No feature extensions are defined in this specification. An example is:
特徴拡張子は全くこの仕様に基づき定義されません。 例は以下の通りです。
Accept-Features: blex, !blebber, colordepth={5}, !screenwidth,
paper = A4, paper!="A2", x-version=104, *
特徴を受け入れます: blexに、blebber、colordepth=5(screenwidthであって、紙の=A4)が=に紙を張る、「A2"、x-バージョンが104、*と等しい、」
The different feature expressions have the following meaning:
異なった特徴式には、以下の意味があります:
ftag ftag is present
ftag ftagは存在しています。
!ftag ftag is absent
ftag ftagは欠けています。
ftag=V ftag is present with the value V
ftag=V ftagは値Vについて存在しています。
ftag!=V ftag is present, but not with the value V
ftag!= V ftagは存在していますが、値Vで存在しているというわけではありません。
ftag={V} ftag is present with the value V, and not with any
other values
ftag=V ftagはいかなる他の値についても存在しているのではなく、値Vについて存在しています。
* the expressions in this header do not fully describe
the feature set: feature tags not mentioned in this
header may also be present, and, except for the case
ftag={V}, tags may be present with more values than
mentioned.
* このヘッダーの式は完全に特徴セットについて説明するというわけではありません: また、このヘッダーで言及されなかった特徴タグも存在しているかもしれません、そして、ケースftag=Vを除いて、タグは言及されるより多くの値について存在しているかもしれません。
Holtman & Mutz Experimental [Page 26] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[26ページ]RFC2295
Absence of the Accept-Features header in a request is equivalent to the inclusion of
要求が、Accept-特徴ヘッダーの不在は包含に同等です。
Accept-Features: *
特徴を受け入れます: *
By using the Accept-Features header, a remote variant selection algorithm can sometimes determine the truth value of a feature predicate on behalf of the user agent. For example, with the header
Accept-特徴ヘッダーを使用することによって、リモート異形選択アルゴリズムはユーザエージェントを代表して特徴述部の真理値を時々決定できます。 例えばヘッダー
Accept-Features: blex, !blebber, colordepth={5}, !screenwidth,
paper = A4, paper!="A2", x-version=104, *
特徴を受け入れます: blexに、blebber、colordepth=5(screenwidthであって、紙の=A4)が=に紙を張る、「A2"、x-バージョンが104、*と等しい、」
the algorithm can determine that the following predicates are true:
アルゴリズムは、以下の述部が本当であることを決定できます:
blex, colordepth=[4-], colordepth!=6, colordepth, !screenwidth,
paper=A4, colordepth=[4-6]
blexに、colordepthが等しい、[4、]、colordepth!=6、colordepth、screenwidth、紙=A4、colordepth=[4-6]
and that the following predicates are false:
そして、以下の述部は誤っています:
!blex, blebber, colordepth=6, colordepth=foo, !colordepth,
screenwidth, screenwidth=640, screenwidth!=640,
blex、blebber、colordepth=6、colordepth=foo、colordepth、screenwidth、screenwidth=640、screenwidth!=640
but the truth value of the following predicates cannot be determined:
しかし、以下の述部の真理値は決定できません:
UA-media=stationary, UA-media!=screen, paper!=a0,
x-version=[100-300], x-version=[200-300], x-version=99,
UA-media=screen, paper=A0, paper=a4, x-version=[100-199], wuxta
UA、-UA-メディア!=スクリーン、紙!=a0、メディア=静止していて、x-バージョンは[100-300]と等しく、x-バージョンは[200-300]と等しく、x-バージョンは99、UA-メディア=スクリーンと等しく、紙はA0と等しく、紙はa4と等しく、x-バージョンは[100-199]、wuxtaと等しいです。
8.3 Alternates
8.3 補欠
The Alternates response header is used to convey the list of variants bound to a negotiable resource. This list can also include directives for any content negotiation process. If a response from a transparently negotiable resource includes an Alternates header, this header MUST contain the complete variant list bound to the negotiable resource. Responses from resources which do not support transparent content negotiation MAY also use Alternates headers.
Alternates応答ヘッダは、交渉可能なリソースに縛られた異形のリストを伝えるのに使用されます。 また、このリストはどんな満足している交渉プロセスのための指示も含むことができます。 透過的に交渉可能なリソースからの応答がAlternatesヘッダーを含んでいるなら、このヘッダーは交渉可能なリソースに縛られた完全な異形リストを含まなければなりません。 また、わかりやすい満足している交渉をサポートしないリソースからの応答はAlternatesヘッダーを使用するかもしれません。
Alternates = "Alternates" ":" variant-list
「補欠は「補欠」と等しい」:、」 異形リスト
variant-list = 1#( variant-description
| fallback-variant
| list-directive )
異形リスト=1#(異形記述| 後退異形| リスト指示)
fallback-variant = "{" <"> URI <"> "}"
後退異形=、「「<、「>ユリ<">"、」、」
list-directive = ( "proxy-rvsa" "=" <"> 0#rvsa-version <"> )
リスト指示=(「プロキシ-rvsa」が<と「等しい」、「>0#rvsa-バージョン<、「>)」
Holtman & Mutz Experimental [Page 27] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[27ページ]RFC2295
| extension-list-directive
| 拡大リスト指示
extension-list-directive =
token [ "=" ( token | quoted-string ) ]
拡大リスト指示=トークン[「=」(トークン| 引用文字列)]
An example is
例はそうです。
Alternates: {"paper.1" 0.9 {type text/html} {language en}},
{"paper.2" 0.7 {type text/html} {language fr}},
{"paper.3" 1.0 {type application/postscript}
{language en}},
proxy-rvsa="1.0, 2.5"
補欠: 「紙の0.1インチ0.9タイプテキスト/html言語アン、「紙の0.2インチ0.7タイプテキスト/html言語fr、「紙の0.3インチ1.0タイプアプリケーション/追伸言語アン、」 1.0、プロキシ-rvsa=2.5インチ」
Any relative URI specified in a variant-description or fallback- variant field is relative to the request-URI. Only one fallback- variant field may be present. If the variant selection algorithm of the user agent finds that all described variants are unacceptable, then it SHOULD choose the fallback variant, if present, as the best variant. If the user agent computes the overall quality values of the described variants, and finds that several variants share the highest value, then the first variant with this value in the list SHOULD be chosen as the best variant.
異形記述か後退異形分野で指定されたどんな相対的なURIも要求URIに比例しています。 1つの後退異形分野だけが存在しているかもしれません。 ユーザエージェント掘り出し物の異形選択アルゴリズムであるなら、すべての説明された異形が容認できなく、次に、それがSHOULDであることは後退異形を選びます、存在しているなら、最も良い異形として。 ユーザエージェントが、説明された異形の総合的な上質の値を計算して、いくつかの異形が最も高い値を共有するのがわかるなら、そして、この値が最も良い異形としてリストSHOULDで選ばれている状態で、最初の異形です。
The proxy-rvsa directive restricts the use of remote variant selection algorithms by proxies. If present, a proxy MUST ONLY use algorithms which have one of the version numbers listed, or have the same major version number and a higher minor version number as one of the versions listed. Any restrictions set by proxy-rvsa come on top of the restrictions set by the user agent in the Negotiate request header. The directive proxy-rvsa="" will disable variant selection by proxies entirely. Clients SHOULD ignore all extension-list- directives they do not understand.
プロキシ-rvsa指示はプロキシによるリモート異形選択アルゴリズムの使用を制限します。 存在しているなら、プロキシには、バージョンの1つが記載したように、バージョン番号の1つを記載するアルゴリズムを使用するだけでよいか、または同じメジャーバージョン番号と、より高いマイナーバージョン番号があるだけでよいです。 代理人を通してどんな制限セットrvsaもNegotiate要求ヘッダーというユーザエージェントによって設定された制限の上で来ます。 」 意志がプロキシによる異形選択を完全に無効にする「指示のプロキシrvsaな=。」 クライアントSHOULDは彼らが理解していないすべての拡大リスト指示を無視します。
A variant list may contain multiple differing descriptions of the same variant. This can be convenient if the variant uses conditional rendering constructs, or if the variant resource returns multiple representations using a multipart media type.
異形リストは同じ異形の複数の異なった記述を含むかもしれません。 異形が条件付きのレンダリング構造物を使用するか、または異形リソースが複合メディアタイプを使用することで複数の表現を返すなら、これは便利である場合があります。
8.4 Negotiate
8.4は交渉されます。
The Negotiate request header can contain directives for any content negotiation process initiated by the request.
Negotiate要求ヘッダーは要求で開始されたどんな満足している交渉プロセスのための指示も含むことができます。
Negotiate = "Negotiate" ":" 1#negotiate-directive
「=「交渉」を交渉してください」:、」 1#、指示を交渉します。
negotiate-directive = "trans"
| "vlist"
| "guess-small"
指示を交渉している=、「移-、」| "vlist"| 「-小さく推測してください」
Holtman & Mutz Experimental [Page 28] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[28ページ]RFC2295
| rvsa-version
| "*"
| negotiate-extension
| rvsa-バージョン| "*" | 拡大を交渉します。
negotiate-extension = token [ "=" token ]
拡大を交渉している=トークン[「=」トークン]
Examples are
例はそうです。
Negotiate: 1.0, 2.5
Negotiate: *
交渉します: 1.0、2.5は交渉されます: *
The negotiate directives have the following meaning
交渉、指示には、以下の意味があります。
"trans"
The user agent supports transparent content negotiation for
the current request.
「移-、」 ユーザエージェントは現在の要求のためのわかりやすい満足している交渉をサポートします。
"vlist"
The user agent requests that any transparently negotiated
response for the current request includes an Alternates
header with the variant list bound to the negotiable resource.
Implies "trans".
現在の要求のためのどんな透過的に交渉された応答も異形リストでAlternatesヘッダーを含んでいるというユーザの"vlist"エージェント要求は交渉可能なリソースにバウンドしています。 含意、「移-、」
"guess-small"
The user agent allows origin servers to run a custom algorithm
which guesses the best variant for the request, and to return
this variant in a choice response, if the resulting choice
response is smaller than or not much larger than a list
response. The definition of `not much larger' is left to
origin server heuristics. Implies "vlist" and "trans".
ユーザエージェントは、要求のために最も良い異形を推測するカスタムアルゴリズムを実行して、特選している応答で「-小さく推測してください」と発生源サーバをこの異形を返させます、結果として起こる特選している応答がリスト応答よりさらに小さいか、またはあまり大きくないなら。 'はるかに大きくないこと'の定義は発生源サーバ発見的教授法に残されます。 そして、"vlist"が含意する、「移-、」
rvsa-version
The user agent allows origin servers and proxies to run the
remote variant selection algorithm with the indicated version
number, or with the same major version number and a higher
minor version number. If the algorithm has sufficient
information to choose a best, neighboring variant, the origin
server or proxy MAY return a choice response with this
variant. Implies "trans".
ユーザエージェントが示されたバージョン番号か、同じメジャーバージョン番号と、より高いマイナーバージョン番号でリモート異形選択アルゴリズムを発生源サーバとプロキシを実行させるrvsa-バージョン。 アルゴリズムにベストを選ぶことができるくらいの情報があるなら、隣接している異形、発生源サーバまたはプロキシがこの異形がある特選している応答を返すかもしれません。 含意、「移-、」
"*"
The user agent allows origin servers and proxies to run any
remote variant selection algorithm. The origin server may
even run algorithms which have not been standardized. If the
algorithm has sufficient information to choose a best,
neighboring variant, the origin server or proxy MAY return a
choice response with this variant. Implies "trans".
ユーザエージェントがどんなリモート異形選択アルゴリズムも発生源サーバとプロキシを実行させる「*。」 発生源サーバは標準化されていないアルゴリズムを実行さえするかもしれません。 アルゴリズムにベストを選ぶことができるくらいの情報があるなら、隣接している異形、発生源サーバまたはプロキシがこの異形がある特選している応答を返すかもしれません。 含意、「移-、」
Holtman & Mutz Experimental [Page 29] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[29ページ]RFC2295
Servers SHOULD ignore all negotiate-directives they do not understand. If the Negotiate header allows a choice between multiple remote variant selection algorithms which are all supported by the server, the server SHOULD use some internal precedence heuristics to select the best algorithm.
サーバSHOULDは指示を交渉している彼らが理解していないすべてを無視します。 Negotiateヘッダーがサーバによってすべてサポートされる複数のリモート異形選択アルゴリズムの選択を許すなら、サーバSHOULDは、最も良いアルゴリズムを選択するのにいくつかの内部の先行発見的教授法を使用します。
8.5 TCN
8.5 TCN
The TCN response header is used by a server to signal that the resource is transparently negotiated.
TCN応答ヘッダはサーバによって使用されて、リソースが透過的に交渉されると合図します。
TCN = "TCN" ":" #( response-type
| server-side-override-directive
| tcn-extension )
「TCNは"TCN"と等しい」:、」 #(応答タイプ| サーバサイドオーバーライド指示| tcn-拡大)
response-type = "list" | "choice" | "adhoc"
応答タイプ=「リスト」| 「選択」| "adhoc"
server-side-override-directive = "re-choose" | "keep"
サーバサイドオーバーライド指示は「再選んでください」と等しいです。| 「保ってください」
tcn-extension = token [ "=" ( token | quoted-string ) ]
tcn-拡大はトークンと等しいです。[「=」(トークン| 引用文字列)]
If the resource is not transparently negotiated, a TCN header MUST NOT be included in any response. If the resource is transparently negotiated, a TCN header, which includes the response-type value of the response, MUST be included in every response with a 2xx status code or any 3xx status code, except 304, in which it MAY be included. A TCN header MAY also be included, without a response-type value, in other responses from transparently negotiated resources.
リソースが透過的に交渉されないなら、どんな応答にもTCNヘッダーを含んではいけません。 リソースが透過的に交渉されるなら、あらゆる応答に2xxステータスコードかどんな3xxステータスコードでもTCNヘッダー(応答の応答タイプ値を含んでいる)を含まなければなりません、304を除いて。そこでは、それが含まれるかもしれません。 また、TCNヘッダーは他の応答に透過的に交渉されたリソースから応答タイプ値なしで含まれるかもしれません。
A server-side override directive MUST be included if the origin server performed a server-side override when choosing the response. If the directive is "re-choose", the server MUST include an Alternates header with the variant bound to the negotiable resource in the response, and user agent SHOULD use its internal variant selection algorithm to choose, retrieve, and display the best variant from this list. If the directive is "keep" the user agent SHOULD NOT renegotiate on the response, but display it directly, or act on it directly if it is a redirection response.
応答を選ぶとき、発生源サーバがサーバサイドオーバーライドを実行したなら、サーバサイドオーバーライド指示を含まなければなりません。 指示が「再選んでください」であり、サーバが応答に交渉可能なリソースに縛られた異形でAlternatesヘッダーを含まなければならなくて、ユーザエージェントSHOULDが選ぶのに内部の異形選択アルゴリズムを使用するなら、このリストから最も良い異形を検索して、表示してください。 指示が「保ってください」であるなら、ユーザエージェントSHOULD NOTは応答に関して再交渉します、直接それを表示するか、またはそれがリダイレクション応答であるなら直接それに影響するのを除いて。
Clients SHOULD ignore all tcn-extensions they do not understand.
クライアントSHOULDは彼らが理解していないすべてのtcn-拡大を無視します。
8.6 Variant-Vary
8.6は異形で異なります。
The Variant-Vary response header can be used in a choice response to record any vary information which applies to the variant data (the entity body combined with some of the entity headers) contained in the response, rather than to the response as a whole.
いずれも全体で応答にというよりむしろ応答に含まれた異形データ(何人かの実体ヘッダーに結合された実体本体)に適用される情報を変えるという記録への特選している応答にVariant異なった応答ヘッダは使用できます。
Holtman & Mutz Experimental [Page 30] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[30ページ]RFC2295
Variant-Vary = "Variant-Vary" ":" ( "*" | 1#field-name )
「異形で異なった=は「異形で異なる」:、」 (「*」| 1#フィールド名)
Use of the Variant-Vary header is discussed in section 10.2.
セクション10.2でVariant異なったヘッダーの使用について議論します。
9 Cache validators
9 キャッシュvalidators
To allow for correct and efficient caching and revalidation of negotiated responses, this specification extends the caching model of HTTP/1.1 [1] in various ways.
交渉された応答の正しくて効率的なキャッシュと再合法化を考慮するために、この仕様はいろいろHTTP/1.1[1]のキャッシングモデルを広げています。
This specification does not introduce a `variant-list-max-age' directive which explicitly bounds the freshness lifetime of a cached variant list, like the `max-age' Cache-Control directive bounds the freshness lifetime of a cached response. However, this specification does ensure that a variant list which is sent at a time T by the origin server will never be re-used without revalidation by semantically transparent caches after the time T+M. This M is the maximum of all freshness lifetimes assigned (using max-age directives or Expires headers) by the origin server to
この仕様は'明らかにキャッシュされた異形リスト、'最大時代'同様のCache-コントロール指示の新しさ生涯バウンドする指示がキャッシュされた応答の新しさ生涯バウンドするa'異形リスト最大時代を導入しません。 しかしながら、この仕様は、時Tに発生源サーバによって送られる異形リストが時間T+Mの後の意味的に透明なキャッシュによって再合法化なしで決して再使用されないのを確実にします。 このMは寿命が発生源サーバによる(最大時代指示を使用するか、Expiresヘッダー)を割り当てたすべての新しさの最大です。
a. the responses from the negotiable resource itself, and
そしてa. 交渉可能なリソース自体からの応答。
b. the responses from its neighboring variant resources
b. 隣接している異形リソースからの応答
If no freshness lifetimes are assigned by the origin server, M is the maximum of the freshness lifetimes which were heuristically assigned by all caches which can re-use the variant list.
新しさ寿命が全く発生源サーバによって割り当てられないなら、Mは異形リストを再使用できるすべてのキャッシュによって発見的に割り当てられた新しさ生涯の最大です。
9.1 Variant list validators
9.1 異形リストvalidators
A variant list validator is an opaque value which acts as the cache validator of a variant list bound to a negotiable resource.
異形リストvalidatorは異形リストのキャッシュvalidatorが交渉可能なリソースに固まったので行動する不透明な値です。
variant-list-validator = <quoted-string not containing any ";">
「異形リストvalidatorはいずれも含まない<引用文字列と等しい」; ">"
If two responses contain the same variant list validator, a cache can treat the Alternates headers in these responses as equivalent (though the headers themselves need not be identical).
2つの応答が同じ異形リストvalidatorを含んでいるなら、キャッシュは同等なこれらの同じくらい応答でAlternatesヘッダーを扱うことができます(ヘッダー自体が同じである必要はありませんが)。
9.2 Structured entity tags
9.2 構造化された実体タグ
A structured entity tag consists of a normal entity tag of which the opaque string is extended with a semicolon followed by the text (without the surrounding quotes) of a variant list validator:
構造化された実体タグは異形リストvalidatorのテキスト(周囲の引用文のない)がセミコロンのあとに続いていて不透明なストリングが広げられる正常な実体タグから成ります:
Holtman & Mutz Experimental [Page 31] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[31ページ]RFC2295
normal | variant list | structured
entity tag | validator | entity tag
-------------+----------------+-----------------
"etag" | "vlv" | "etag;vlv"
W/"etag" | "vlv" | W/"etag;vlv"
標準| 異形リスト| 構造化された実体タグ| validator| 実体タグ-------------+----------------+----------------- "etag"| "vlv"| 「」 etagに伴う「etag、vlv」」| "vlv"| 「」 etag; vlvする、」
Note that a structured entity tag is itself also an entity tag. The structured nature of the tag allows caching proxies capable of transparent content negotiation to perform some optimizations defined in section 10. When not performing such optimizations, a structured tag SHOULD be treated as a single opaque value, according to the general rules in HTTP/1.1. Examples of structured entity tags are:
また、構造化された実体タグがそれ自体で実体タグであることに注意してください。 タグの構造化された自然は、セクション10で定義されたいくつかの最適化を実行するためにわかりやすい満足している交渉ができるプロキシをキャッシュさせます。 そのような最適化を実行しないとき、aはただ一つの不透明な値として扱われた状態でタグSHOULDを構造化しました、HTTP/1.1における総則によると。 構造化された実体タグに関する例は以下の通りです。
"xyzzy;1234" W/"xyzzy;1234" "gonkxxxx;1234" "a;b;c;;1234"
「「xyzzy; 」 xyzzyがある1234インチ; 1234」、「gonkxxxx; 1234 」 「; b;c」1234"
In the last example, the normal entity tag is "a;b;c;" and the variant list validator is "1234".
最後の例では、正常な実体タグは「; b;c」です。 そして、異形リストvalidatorは「1234」です。
If a transparently negotiated response includes an entity tag, it MUST be a structured entity tag. The variant list validator in the structured tag MUST act as a validator for the variant list contained in the Alternates header. The normal entity tag in the structured tag MUST act as a validator of the entity body in the response and of all entity headers except Alternates.
透過的に交渉された応答が実体タグを含んでいるなら、それは構造化された実体タグであるに違いありません。 構造化されたタグの異形リストvalidatorは異形リストのためのvalidatorとしてAlternatesヘッダーに含まれているのに作動しなければなりません。 構造化されたタグの正常な実体タグは応答における実体本体とAlternates以外のすべての実体ヘッダーのvalidatorとして作用しなければなりません。
9.3 Assigning entity tags to variants
9.3 実体タグを異形に割り当てること。
To allow for correct revalidation of transparently negotiated responses by clients, origin servers SHOULD generate all normal entity tags for the neighboring variant resources of the negotiable resource in such a way that
クライアント、SHOULDが生成する発生源サーバで透過的に交渉された応答の正しい再合法化を考慮するために、すべての正常な実体がそのような方法による交渉可能なリソースの隣接している異形リソースのためにそれにタグ付けをします。
1. the same tag is never used by two different variants,
unless this tag labels exactly the same entity on all occasions,
1. 同じタグは2つの異なった異形によって決して使用されません、このタグがどんな時にもまさに同じ実体をラベルしない場合
2. if one normal tag "X" is a prefix of another normal tag "XY",
then "Y" must never be a semicolon followed by a variant list
validator.
2. 1個の正常なタグ「X」が別の正常なタグ"XY"の接頭語であるなら、「Y」は決して異形リストvalidatorによっていうことになられたセミコロンでないに違いありません。
10 Content negotiation responses
10 満足している交渉応答
If a request on a transparently negotiated resource yields a response with a 2xx status code or any 3xx status code except 304, this response MUST always be either a list response, a choice response, or an adhoc response. These responses MUST always include a TCN header which specifies their type. Transparently negotiated responses with other status codes MAY also include a TCN header.
透過的に交渉されたリソースに関する要求が2xxステータスコードか304以外のどんな3xxステータスコードによる応答ももたらすなら、いつも、この応答は、リスト応答、特選している応答、またはadhoc応答であるに違いありません。 これらの応答はいつも彼らのタイプを指定するTCNヘッダーを含まなければなりません。 また、他のステータスコードによる透過的に交渉された応答はTCNヘッダーを含むかもしれません。
Holtman & Mutz Experimental [Page 32] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[32ページ]RFC2295
The conditions under which the different content negotiation responses may be sent are defined in section 12.1 for origin servers and in section 13 for proxies.
異なった満足している交渉応答が送られるかもしれない状態は発生源サーバのためのセクション12.1とプロキシのためのセクション13で定義されます。
After having constructed a list, choice, or adhoc response, a server MAY process any If-No-Match or If-Range headers in the request message and shorten the response to a 304 (Not Modified) or 206 (Partial Content) response, following the rules in the HTTP/1.1 specification [1]. In this case, the entity tag of the shortened response will identify it indirectly as a list, choice, or adhoc response.
リスト、選択、またはadhoc応答を構成した後に、サーバは、要求メッセージでどんなIfいいえマッチやIf-範囲ヘッダーも処理して、304(Modifiedでない)か206(部分的なContent)応答への応答を短くするかもしれません、HTTP/1.1仕様[1]で約束を守って。 この場合、短くされた応答の実体タグは間接的にリスト、選択、またはadhoc応答としてそれを特定するでしょう。
10.1 List response
10.1 リスト応答
A list response returns the variant list of the negotiable resource, but no variant data. It can be generated when the server does not want to, or is not allowed to, return a particular best variant for the request. If the user agent supports transparent content negotiation, the list response will cause it to select a best variant and retrieve it.
リスト応答は交渉可能なリソースにもかかわらず、異形データがない異形リストを返します。 それは、サーバを生成されたくないと生成することができるか、または許容されていなくて、リターンは要求のための特定の最も良い異形です。 ユーザエージェントがわかりやすい満足している交渉をサポートすると、リスト応答は最も良い異形を選択して、それを検索することを引き起こすでしょう。
A list response MUST contain (besides the normal headers required by HTTP) a TCN header which specifies the "list" response-type, the Alternates header bound to the negotiable resource, a Vary header and (unless it was a HEAD request) an entity body which allows the user to manually select the best variant.
リスト応答は「リスト」応答タイプ(交渉可能なリソース、Varyヘッダー、およびユーザが手動で選択できる中で異形最も良い(それがHEAD要求でなかったなら)実体本体に縛られたAlternatesヘッダー)を指定するTCNヘッダーを含まなければなりません(HTTPによって必要とされた普通のヘッダー以外に)。
An example of a list response is
リスト応答に関する例はそうです。
HTTP/1.1 300 Multiple Choices
Date: Tue, 11 Jun 1996 20:02:21 GMT
TCN: list
Alternates: {"paper.1" 0.9 {type text/html} {language en}},
{"paper.2" 0.7 {type text/html} {language fr}},
{"paper.3" 1.0 {type application/postscript}
{language en}}
Vary: negotiate, accept, accept-language
ETag: "blah;1234"
Cache-control: max-age=86400
Content-Type: text/html
Content-Length: 227
HTTP/1.1 300の選択式日付: グリニッジ標準時1996年6月11日火曜日20時2分21秒TCN: Alternatesを記載してください: 「紙の0.1インチ0.9タイプテキスト/html言語アン、「紙の0.2インチ0.7タイプテキスト/html言語fr、「紙の0.3インチ1.0タイプアプリケーション/追伸言語アン、異なります:、」 交渉してくださいといって、言語を受け入れて受け入れてください、ETag: 「たわごと; 1234」はキャッシュで制御されます: =86400コンテントタイプの最大に年をとってください: html Contentテキスト/長さ: 227
<h2>Multiple Choices:</h2>
<ul>
<li><a href=paper.1>HTML, English version</a>
<li><a href=paper.2>HTML, French version</a>
<li><a href=paper.3>Postscript, English version</a>
</ul>
<h2>倍数Choices: </h2><ul><li><a hrefは紙.1の>HTMLと等しく、英語版</a><li><a hrefは紙.2の>HTMLと等しく、フランスのバージョン</a><li><a hrefは紙.3の>Postscript、英語版</a></ul>と等しいです。
Holtman & Mutz Experimental [Page 33] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[33ページ]RFC2295
Note: A list response can have any status code, but the 300
(Multiple Choices) code is the most appropriate one for HTTP/1.1
clients. Some existing versions of HTTP/1.0 clients are known to
silently ignore 300 responses, instead of handling them according
to the HTTP/1.0 specification [2]. Servers should therefore be
careful in sending 300 responses to non-negotiating HTTP/1.0 user
agents, and in making these responses cacheable. The 200 (OK)
status code can be used instead.
以下に注意してください。 リスト応答はどんなステータスコードも持つことができますが、300(複数のChoices)コードはHTTP/1.1人のクライアントのための最も適切なものです。 HTTP/1.0人のクライアントのいくつかの既存のバージョンが静かに300の応答を無視するのが知られています、HTTP/1.0仕様[2]通りにそれらを扱うことの代わりに。 したがって、サーバはHTTP/1.0人の非交渉しているユーザエージェントに300の応答を送って、これらの応答を「キャッシュ-可能」にするのにおいて慎重であるはずです。 代わりに200(OK)ステータスコードを使用できます。
The Vary header in the response SHOULD ensure correct handling by plain HTTP/1.1 caching proxies. This header can either be
SHOULDがプロキシをキャッシュする明瞭なHTTP/1.1で正しい取り扱いを確実にする応答におけるVaryヘッダー。 このヘッダーはあることができます。
Vary: *
異なります: *
or a more elaborate header; see section 10.6.1.
より細かいヘッダー。 セクション10.6.1を見てください。
Only the origin server may construct list responses. Depending on the status code, a list response is cacheable unless indicated otherwise.
発生源サーバだけがリスト応答を構成するかもしれません。 ステータスコードによって、別の方法で示されない場合、リスト応答は「キャッシュ-可能」です。
According to the HTTP/1.1 specification [1], a user agent which does not support transparent content negotiation will, when receiving a list response with the 300 status code, display the entity body included in the response. If the response contains a Location header, however, the user agent MAY automatically redirect to this location.
300ステータスコードでリスト応答を受けるとき、サポートではなく、HTTP/1.1仕様[1]、そうするユーザエージェントによると、応答に実体本体を含んでいると、わかりやすい満足している交渉は表示するでしょう。 しかしながら、応答がLocationヘッダーを含んでいるなら、ユーザエージェントは自動的にこの位置に再直接で含んでいます。
The handling of list responses by clients supporting transparent content negotiation is described in sections 11.1 and 13.
わかりやすい満足している交渉をサポートするクライアントによるリスト応答の取り扱いはセクション11.1と13で説明されます。
10.2 Choice response
10.2 特選している応答
A choice response returns a representation of the best variant for the request, and may also return the variant list of the negotiable resource. It can be generated when the server has sufficient information to be able to choose the best variant on behalf the user agent, but may only be generated if this best variant is a neighboring variant. For request from user agents which do not support transparent content negotiation, a server may always generate a choice response, provided that the variant returned is a neighboring variant. The variant returned in a choice response need not necessarily be listed in the variant list bound to the negotiable resource.
特選している応答は、要求のために最も良い異形の表現を返して、また、交渉可能なリソースの異形リストを返すかもしれません。 生成されて、サーバにはいつまで十分な情報があるかが利益で最も良い異形にユーザエージェントを選ぶことができますが、この最も良い異形が隣接している異形である場合にだけ生成されるかもしれないということであるかもしれません。 ユーザエージェントからの要求のために、どれが、見え透いた内容が交渉、サーバであるとサポートしないかが返された異形が隣接している異形であればいつも特選している応答を生成するかもしれません。 特選している応答で返された異形は必ず交渉可能なリソースに縛られた異形リストに記載されていなければならないというわけではありません。
Holtman & Mutz Experimental [Page 34] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[34ページ]RFC2295
A choice response merges a normal HTTP response from the chosen variant, a TCN header which specifies the "choice" response-type, and a Content-Location header giving the location of the variant. Depending on the status code, a choice response is cacheable unless indicated otherwise.
特選している応答は選ばれた異形、「特選している」応答タイプ、および異形の位置を与えるContent-位置のヘッダーを指定するTCNヘッダーから通常のHTTP応答を合併します。 ステータスコードによって、別の方法で示されない場合、特選している応答は「キャッシュ-可能」です。
Origin servers and proxy caches MUST construct choice responses with the following algorithm (or any other algorithm which gives equal end results for the client).
以下のアルゴリズム(または、クライアントのために等しい結末を与えるいかなる他のアルゴリズムも)で発生源サーバとプロキシキャッシュは特選している応答を構成しなければなりません。
In this algorithm, `the current Alternates header' refers to the Alternates header containing the variant list which was used to choose the best variant, and `the current variant list validator' refers to the validator of this list. Section 10.4 specifies how these two items can be obtained by a proxy cache.
このアルゴリズムで、'現在のAlternatesヘッダー'は最も良い異形を選ぶのに使用された異形リストを含むAlternatesヘッダーについて言及します、そして、'現在の異形リストvalidator'はこのリストのvalidatorについて言及します。 セクション10.4はプロキシキャッシュでどうこれらの2個の商品を入手できるかを指定します。
The algorithm consists of four steps.
アルゴリズムは4ステップから成ります。
1. Construct a HTTP request message on the best variant resource
by rewriting the request-URI and Host header (if appropriate) of
the received request message on the negotiable resource.
1. 交渉可能なリソースに関する受信された要求メッセージの要求URIとHostヘッダー(適切であるなら)を書き直すことによって、最も良い異形リソースに関するHTTP要求メッセージを構成してください。
2. Generate a valid HTTP response message, but not one with the
304 (Not Modified) code, for the request message constructed in
step 1.
2. 304(Modifiedでない)がある1ではなく、有効なHTTP応答メッセージがコードであると生成してください、ステップ1で構成された要求メッセージのために。
In a proxy cache, the response can be obtained from cache
memory, or by passing the constructed HTTP request towards the
origin server. If the request is passed on, the proxy MAY add,
modify, or delete If-None-Match and If-Range headers to optimize
the transaction with the upstream server.
プロキシキャッシュでは、キャッシュメモリ、または組み立てられたHTTP要求に発生源サーバに向かって合格することによって、応答を得ることができます。要求が伝えられるなら、プロキシは、上流のサーバでトランザクションを最適化するためになにも合わせないIfとIf-範囲ヘッダーを加えるか、変更するか、または削除するかもしれません。
Note: the proxy should be careful not to add entity tags of
non-neighboring variants to If-* (conditional) headers of the
request, as there are no global uniqueness requirements for
these tags.
以下に注意してください。 プロキシは要求のIf-*(条件付き)のヘッダーに非隣接している異形の実体タグを加えないように慎重であるはずです、これらのタグのためのどんなグローバルなユニークさの要件もないとき。
3. Only in origin servers: check for an origin server
configuration error. If the HTTP response message generated in
step 2 contains a TCN header, then the best variant resource is
not a proper end point in the transparent negotiation process,
and a 506 (Variant Also Negotiates) error response message
SHOULD be generated instead of going to step 4.
3. 発生源サーバだけで: 発生源サーバ構成誤りがないかどうかチェックしてください。 ステップ2で生成されたHTTP応答メッセージがTCNヘッダーを含んでいるなら、最も良い異形リソースは、透明な交渉プロセスの適切なエンドポイントと、または506(異形Also Negotiates)誤り応答メッセージSHOULDではありません。4を踏む行くことの代わりに、生成されてください。
4. Add a number of headers to the HTTP response message generated
in step 2.
4. ステップ2で生成されたHTTP応答メッセージに多くのヘッダーを追加してください。
Holtman & Mutz Experimental [Page 35] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[35ページ]RFC2295
a. Add a TCN header which specifies the "choice"
response-type.
a。 「特選している」応答タイプを指定するTCNヘッダーを加えてください。
b. Add a Content-Location header giving the location of the
chosen variant. Delete any Content-Location header which was
already present.
b。 選ばれた異形の位置を与えるContent-位置のヘッダーを加えてください。 あらゆる既に出席しているContent-位置のヘッダーを削除してください。
Note: According to the HTTP/1.1 specification [1], if the
Content-Location header contains a relative URI, this URI
is relative to the URI in the Content-Base header, if
present, and relative to the request-URI if no Content-
Base header is present.
以下に注意してください。 HTTP/1.1仕様[1]に従って、Content-位置のヘッダーが相対的なURIを含んでいるなら、このURIは、Content-基地のヘッダーのURIに比例していて、出席しています、そして、要求URIに比例して、ヘッダーはContent基地でないなら出席しています。
c. If any Vary headers are present in the response message
from step 2, add, for every Vary header, a Variant-Vary
header with a copy of the contents of this Vary header.
c。 ステップ2によって、どれかVaryヘッダーが応答メッセージで出席しているなら、すべてのVaryヘッダーには、このVaryヘッダーのコンテンツのコピーでVariant異なったヘッダーを加えてください。
d. Delete any Alternates headers which are present in in the
response. Now, the current Alternates header MUST be added
if this is required by the Negotiate request header, or if
the server returns "re-choose" in the TCN response header.
Otherwise, the current Alternates header MAY be added.
d。 応答でどんな出席しているAlternatesヘッダーも削除します。 現在、これがNegotiate要求ヘッダーによって必要とされるか、またはサーバがTCN応答ヘッダで「再選んでください」を返すなら、現在のAlternatesヘッダーを加えなければなりません。 さもなければ、現在のAlternatesヘッダーは加えられるかもしれません。
Note: It is usually a good strategy to always add the
current Alternates header, unless it is very large
compared to the rest of the response.
以下に注意してください。 通常、いつも現在のAlternatesヘッダーを加えるのは、優れた戦略です、応答の残りと比べて、それがそれほど大きくない場合。
e. Add a Vary header to ensure correct handling by plain
HTTP/1.1 caching proxies. This header can either be
e。 Varyヘッダーを加えて、プロキシをキャッシュする明瞭なHTTP/1.1で正しい取り扱いを確実にしてください。 このヘッダーはあることができます。
Vary: *
or a more elaborate header, see section 10.6.
異なります: * または、aより細かいヘッダーはセクション10.6を見てください。
f. To ensure compatibility with HTTP/1.0 caching proxies which
do not recognize the Vary header, an Expires header with a
date in the past MAY be added. See section 10.7 for more
information.
f。 そうしないプロキシをキャッシュするHTTP/1.0との互換性を確実にするには、Varyヘッダー(日付が過去の5月に加えられているExpiresヘッダー)を見分けてください。 詳しい情報に関してセクション10.7を見てください。
g. If an ETag header is present in the response message from
step 2, then extend the entity tag in that header with the
current variant list validator, as specified in section 9.2.
g。 ステップ2によって、ETagヘッダーが応答メッセージで出席しているなら、そのヘッダーで現在の異形リストvalidatorで実体タグを広げてください、セクション9.2で指定されるように。
Note: Step g. is required even if the variant list itself
is not added in step d.
以下に注意してください。 異形リスト自体がステップdで加えられないでも、ステップg.が必要です。
h. Only in proxy caches: set the Age header of the response to
h。 プロキシキャッシュだけで: 応答のAgeヘッダーを設定します。
max( variant_age , alternates_age )
最大(異形_時代、補欠_時代)
Holtman & Mutz Experimental [Page 36] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[36ページ]RFC2295
where variant_age is the age of the variant response obtained
in step 2, calculated according to the rules in the HTTP/1.1
specification [1], and alternates_age is the age of the
Alternates header added in step d, calculated according to
the rules in section 10.4.
異形_時代がどこに規則に従ってHTTP/1.1仕様[1]で計算されたステップ2で得られた異形応答の時代であり、_時代を交替するかは、ステップdで加えられて、規則に従ってセクション10.4で計算高いAlternatesヘッダーの年令です。
Note that a server can shorten the response produced by the above algorithm to a 304 (Not Modified) response if an If-None-Match header in the original request allows it. If this is the case, an implementation of the above algorithm can avoid the unnecessary internal construction of full response message in step 2, it need only construct the parts which end up in the final 304 response. A proxy cache which implements this optimization can sometimes generate a legal 304 response even if it has not cached the variant data itself.
サーバがオリジナルの要求におけるなにも合わせないIfヘッダーがそれを許容するなら上のアルゴリズムで304(Modifiedでない)応答に起こされた応答を短くすることができることに注意してください。 これがそうであるなら、上のアルゴリズムの実装はステップ2における、完全な応答メッセージの不要な内部の工事を避けることができて、それは最終的な304応答で終わる部品を組み立てるだけでよいです。 異形データ自体をキャッシュしていなくても、この最適化を実装するプロキシキャッシュは時々法的な304応答を生成することができます。
An example of a choice response is:
特選している応答に関する例は以下の通りです。
HTTP/1.1 200 OK
Date: Tue, 11 Jun 1996 20:05:31 GMT
TCN: choice
Content-Type: text/html
Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT
Content-Length: 5327
Cache-control: max-age=604800
Content-Location: paper.1
Alternates: {"paper.1" 0.9 {type text/html} {language en}},
{"paper.2" 0.7 {type text/html} {language fr}},
{"paper.3" 1.0 {type application/postscript}
{language en}}
Etag: "gonkyyyy;1234"
Vary: negotiate, accept, accept-language
Expires: Thu, 01 Jan 1980 00:00:00 GMT
HTTP/1.1 200OK日付: グリニッジ標準時1996年6月11日火曜日20時5分31秒TCN: 特選しているコンテントタイプ: htmlテキスト/最終更新日: グリニッジ標準時1996年6月10日月曜日10時1分14秒のコンテンツの長さ: 5327年のキャッシュ制御: 最大時代は604800Content-位置と等しいです: 紙.1のAlternates: 「紙の0.1インチ0.9タイプテキスト/html言語アン、「紙の0.2インチ0.7タイプテキスト/html言語fr、「紙の0.3インチ1.0タイプアプリケーション/追伸言語アン、Etag:、」 「gonkyyyy; 1234はインチ異なります: 交渉してくださいといって、言語を受け入れて受け入れてください、Expires: グリニッジ標準時1980年1月1日木曜日0時0分0秒
<title>A paper about ....
<、>Aを紙と題をつけます。
10.3 Adhoc response
10.3 Adhoc応答
An adhoc response can be sent by an origin server as an extreme measure, to achieve compatibility with a non-negotiating or buggy client if this compatibility cannot be achieved by sending a list or choice response. There are very little requirements on the contents of an adhoc response. An adhoc response MUST have a TCN header which specifies the "adhoc" response-type, and a Vary header if the response is cacheable. It MAY contain the Alternates header bound to the negotiable resource.
発生源サーバで思いきった手段としてadhoc応答を送ることができて、非交渉かバギーとの互換性を獲得するために、この互換性であるならリストか特選している応答を送ることによって、クライアントを達成できません。 adhoc応答のコンテンツに関する非常に小さい要件があります。 adhoc応答には、"adhoc"応答タイプを指定するTCNヘッダーがなければなりません、そして、Varyヘッダーは応答であるなら「キャッシュ-可能」です。 それは交渉可能なリソースに縛られたAlternatesヘッダーを含むかもしれません。
Holtman & Mutz Experimental [Page 37] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[37ページ]RFC2295
Any Vary header in the response SHOULD ensure correct handling by plain HTTP/1.1 caching proxies. This header can either be
SHOULDがプロキシをキャッシュする明瞭なHTTP/1.1で正しい取り扱いを確実にする応答におけるどんなVaryヘッダー。 このヘッダーはあることができます。
Vary: *
異なります: *
or a more elaborate header, see section 10.6.1. Depending on the status code, an adhoc response is cacheable unless indicated otherwise.
または、aより細かいヘッダーはセクション10.6.1を見てください。 ステータスコードによって、別の方法で示されない場合、adhoc応答は「キャッシュ-可能」です。
As an example of the use of an adhoc response, suppose that the variant resource "redirect-to-blah" yields redirection (302) responses. A choice response with this variant could look as follows:
adhoc応答の使用に関する例として、「たわごとへの再直接」の異形リソースがリダイレクション(302)応答をもたらすと仮定してください。 この異形がある特選している応答は以下の通りに見えることができました:
HTTP/1.1 302 Moved Temporarily
Date: Tue, 11 Jun 1996 20:02:28 GMT
TCN: choice
Content-location: redirect-to-blah
Location: http://blah.org/
Content-Type: text/html
Content-Length: 62
HTTP/1.1 302は一時日付:を動かしました。 グリニッジ標準時1996年6月11日火曜日20時2分28秒TCN: 特選しているContent-位置: たわごとに再直接のLocation: http://blah.org/ コンテントタイプ: html Contentテキスト/長さ: 62
This document is available <a href=http://blah.org/>here</a>.
このドキュメントはここの http://blah.org/ 利用可能な<a href=>です。</a>。
Suppose that the server knows that the receiving user agent has a bug, which causes it to crash on responses which contain both a Content-Location and a Location header. The server could then work around this bug by performing a server-side override and sending the following adhoc response instead:
サーバが、受信ユーザエージェントがそれがContent-位置とLocationヘッダーの両方を含む応答のときにダウンするバグを持っているのを知っていると仮定してください。 次に、サーバはこのバグの周りでサーバサイドオーバーライドを実行して、代わりに以下のadhoc応答を送ることによって、動作できるでしょう:
HTTP/1.1 302 Moved Temporarily
Date: Tue, 11 Jun 1996 20:02:28 GMT
TCN: adhoc, keep
Location: http://blah.org/
Content-Type: text/html
Content-Length: 62
HTTP/1.1 302は一時日付:を動かしました。 グリニッジ標準時1996年6月11日火曜日20時2分28秒TCN: adhoc、Locationを保ってください: http://blah.org/ コンテントタイプ: html Contentテキスト/長さ: 62
This document is available <a href=http://blah.org/>here</a>.
このドキュメントはここの http://blah.org/ 利用可能な<a href=>です。</a>。
10.4 Reusing the Alternates header
10.4 Alternatesヘッダーを再利用すること。
If a proxy cache has available a negotiated response which is cacheable, fresh, and has ETag and Alternates headers, then it MAY extract the Alternates header and associated variant list validator from the response, and reuse them (without unnecessary delay) to
プロキシキャッシュに生々しく「キャッシュ-可能」で、ETagとAlternatesヘッダーがある利用可能な交渉された応答があるなら、それはヘッダーと関連異形が応答からvalidatorを記載して、彼ら(不要な遅れのない)を再利用するAlternatesを抽出するかもしれません。
Holtman & Mutz Experimental [Page 38] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[38ページ]RFC2295
negotiate on behalf of the user agent (section 13) or to construct a choice response (section 10.2). The age of the extracted Alternates header is the age of the response from which it is extracted, calculated according to the rules in the HTTP/1.1 specification [1].
ユーザエージェント(セクション13)を代表した構造物と特選している応答(セクション10.2)を交渉してください。 抽出されたAlternatesヘッダーの年令は規則に従って、それがHTTP/1.1仕様[1]で抽出されて、計算されている応答の時代です。
10.5 Extracting a normal response from a choice response
10.5 特選している応答から通常の応答を抽出すること。
If a proxy receives a choice response, it MAY extract and cache the normal HTTP response contained therein. The normal response can be extracted by taking a copy of the choice response and then deleting any Content-Location, Alternates, and Vary headers, renaming any Variant-Vary headers to Vary headers, and shortening the structured entity tag in any ETag header to a normal entity tag.
プロキシが特選している応答を受けるなら、それは、そこに含まれた通常のHTTP応答を、抽出して、キャッシュするかもしれません。 特選している応答のコピーを取って、次に、どんなContent-位置、Alternates、およびVaryヘッダーも削除することによって、通常の応答を抽出できます、どんなVariant異なったヘッダーもVaryヘッダーに改名して、どんなETagヘッダーでも正常な実体タグに構造化された実体タグを短くして。
This normal response MAY be cached (as a HTTP response to the variant request as constructed in step 1. of section 10.2) and reused to answer future direct requests on the variant resource, according to the rules in the HTTP/1.1 specification [1].
この通常の応答は、異形リソースに関する今後のダイレクト要求に答えるためにキャッシュされて(セクション10.2のステップ1で構成される異形要求へのHTTP応答として)、再利用されるかもしれません、HTTP/1.1仕様[1]による規則に従って。
Note: The caching of extracted responses can decrease the upstream
bandwidth usage with up to a factor 2, because two independent
HTTP/1.1 cache entries, one associated with the negotiable
resource URI and one with the variant URI, are created in the same
transaction. Without this optimization, both HTTP/1.1 cache
entries can only be created by transmitting the variant data
twice.
以下に注意してください。 抽出されることのキャッシュ、2の独立しているHTTP/1.1がエントリーをキャッシュするので応答が上流の帯域幅用法を要素2まで減少させることができる交渉可能なリソースURIに関連づけられたもの、および異形URIがある1つは同じトランザクションで作成されます。 この最適化がなければ、二度異形データを送ることによって、両方のHTTP/1.1のキャッシュエントリーしか作成できません。
For security reasons (see section 14.2), an extracted normal response MUST NEVER be cached if belongs to a non-neighboring variant resource. If the choice response claims to contain data for a non- neighboring variant resource, the proxy SHOULD reject the choice response as a probable spoofing attempt.
安全保障上の理由で(セクション14.2を見る)、抽出された通常の応答を決してキャッシュしてはいけない、非隣接している異形リソースに属します。 特選している応答が、非隣接している異形リソースのためのデータを含むと主張するなら、プロキシSHOULDはありえそうなスプーフィング試みとして特選している応答を拒絶します。
10.6 Elaborate Vary headers
10.6 細かいVaryヘッダー
If a HTTP/1.1 [1] server can generate varying responses for a request on some resource, then the server MUST include a Vary header in these responses if they are cacheable. This Vary header is a signal to HTTP/1.1 caches that something special is going on. It prevents the caches from returning the currently chosen response for every future request on the resource.
HTTP/1.1[1]サーバが何らかのリソースに関する要求のための異なった応答を生成することができるなら、それらが「キャッシュ-可能」であるなら、サーバはこれらの応答にVaryヘッダーを含まなければなりません。 このVaryヘッダーはHTTP/1.1のキャッシュへの何か特別なものが先へ進んでいるという信号です。 それは、キャッシュがリソースに関するあらゆる今後の要求のための現在選ばれた応答を返すのを防ぎます。
Servers engaging in transparent content negotiation will generate varying responses. Therefore, cacheable list, choice, and adhoc responses MUST always include a Vary header.
わかりやすい満足している交渉に従事しているサーバが異なった応答を生成するでしょう。 したがって、「キャッシュ-可能」リスト、選択、およびadhoc応答はいつもVaryヘッダーを含まなければなりません。
Holtman & Mutz Experimental [Page 39] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[39ページ]RFC2295
The most simple Vary header which can be included is
含むことができる中で最も簡単なVaryヘッダーはそうです。
Vary: *
異なります: *
This header leaves the way in which the response is selected by the server completely unspecified.
このヘッダーは応答がサーバによって完全に不特定の状態で選択される方法を残します。
A more elaborate Vary header MAY be used to allow for certain optimizations in HTTP/1.1 caches which do not have specific optimizations for transparent content negotiation, but which do cache multiple variant responses for one resource. Such a more elaborate Vary header lists all request headers which can be used by the server when selecting a response for a request on the resource.
より細かいVaryヘッダーは、わかりやすい満足している交渉のために特定の最適化を持っていませんが、1つのリソースのために複数の異形応答をキャッシュするHTTP/1.1のキャッシュにおける、ある最適化を考慮するのに使用されるかもしれません。 そのようなより細かいVaryヘッダーはリソースに関する要求のための応答を選択するときサーバで使用できるすべての要求ヘッダーを記載します。
10.6.1 Construction of an elaborate Vary header
10.6.1 細かいVaryヘッダーの構造
Origin servers can construct a more elaborate Vary header in the following way. First, start with the header
発生源サーバは以下の方法でより細かいVaryヘッダーを組み立てることができます。 まず最初に、ヘッダーから始めてください。
Vary: negotiate
異なります: 交渉してください。
`negotiate' is always included because servers use the information in the Negotiate header when choosing between a list, choice, or adhoc response.
リスト、選択、またはadhoc応答を選ぶとき、サーバがNegotiateヘッダーで情報を使用するので、'交渉してください'はいつも含まれています。
Then, if any of the following attributes is present in any variant description in the Alternates header, add the corresponding header name to the Vary header
そして、以下の属性のどれかがAlternatesヘッダーのどんな異形記述でも存在しているなら、対応するヘッダー名をVaryヘッダーに加えてください。
attribute | header name to add
-----------+---------------------
type | accept
charset | accept-charset
language | accept-language
features | accept-features
属性| 加えるヘッダー名-----------+--------------------- タイプ| charsetを受け入れてください。| charsetを受け入れている言語| 言語を受け入れている特徴| 特徴を受け入れます。
The Vary header constructed in this way specifies the response variation which can be caused by the use of a variant selection algorithm in proxies. If the origin server will in some cases, for example if contacted by a non-negotiating user agent, use a custom negotiation algorithm which takes additional headers into account, these names of these headers SHOULD also be added to the Vary header.
このように組み立てられたVaryヘッダーはプロキシにおける異形選択アルゴリズムの使用で引き起こされる場合がある応答変化を指定します。 例えば、非交渉しているユーザエージェントが連絡されると発生源サーバがいくつかの場合そうするなら、アカウント、これらのこれらの名前への追加ヘッダーのためにヘッダーSHOULDを取るカスタム交渉アルゴリズムを使用してください、そして、また、Varyヘッダーに加えられてください。
Holtman & Mutz Experimental [Page 40] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[40ページ]RFC2295
10.6.2 Caching of an elaborate Vary header
10.6.2 細かいVaryヘッダーのキャッシュ
A proxy cache cannot construct an elaborate vary header using the method above, because this method requires exact knowledge of any custom algorithms present in the origin server. However, when extracting an Alternates header from a response (section 10.4) caches MAY also extract the Vary header in the response, and reuse it along with the Alternates header. A clean Vary header can however only be extracted if the variant does not vary itself, i.e. if a Variant-Vary header is absent.
上でメソッドを使用することでヘッダーを変えてください、このメソッドが発生源サーバにおける現在のどんなカスタムアルゴリズムに関する正確な知識も必要とするので。詳述してください。プロキシキャッシュが組み立てることができない、応答(セクション10.4)からAlternatesヘッダーを抽出するとき、しかしながら、キャッシュは、また、応答でVaryヘッダーを抽出して、Alternatesヘッダーと共にそれを再利用してもよいです。 しかしながら、異形がそれ自体を変えない場合にだけ、清潔なVaryヘッダーを抽出できます、すなわち、Variant異なったヘッダーが欠けるなら。
10.7 Adding an Expires header for HTTP/1.0 compatibility
10.7 HTTP/1.0の互換性のためにExpiresヘッダーを加えること。
To ensure compatibility with HTTP/1.0 caching proxies which do not recognize the Vary header, an Expires header with a date in the past can be added to the response, for example
Varyヘッダーを見分けないプロキシをキャッシュするHTTP/1.0との互換性を確実にするために、例えば、過去の日付があるExpiresヘッダーを応答に加えることができます。
Expires: Thu, 01 Jan 1980 00:00:00 GMT
期限が切れます: グリニッジ標準時1980年1月1日木曜日0時0分0秒
If this is done by an origin server, the server SHOULD usually also include a Cache-Control header for the benefit of HTTP/1.1 caches, for example
また、例えば、発生源サーバでこれをするなら、通常、サーバSHOULDはHTTP/1.1のキャッシュの利益のためのCache-コントロールヘッダーを含んでいます。
Cache-Control: max-age=604800
キャッシュ制御: 最大時代=604800
which overrides the freshness lifetime of zero seconds specified by the included Expires header.
含まれているExpiresヘッダーによって指定された秒がない新しさ生涯をくつがえします。
Note: This specification only claims downwards compatibility with
the HTTP/1.0 proxy caches which implement the HTTP/1.0
specification [2]. Some legacy proxy caches which return the
HTTP/1.0 protocol version number do not honor the HTTP/1.0 Expires
header as specified in [2]. Methods for achieving compatibility
with such proxy caches are beyond the scope of this specification.
以下に注意してください。 この仕様は下向きにHTTP/1.0仕様が[2]であると実装するHTTP/1.0のプロキシキャッシュとの互換性を要求するだけです。 HTTP/1.0プロトコルバージョン番号を返すいくつかのレガシープロキシキャッシュが[2]の指定されるとしてのHTTP/1.0Expiresヘッダーを尊敬しません。 そのようなプロキシキャッシュとの互換性を獲得するためのメソッドはこの仕様の範囲を超えています。
10.8 Negotiation on content encoding
10.8 満足しているコード化の交渉
Negotiation on the content encoding of a response is orthogonal to transparent content negotiation. The rules for when a content encoding may be applied are the same as in HTTP/1.1: servers MAY content-encode responses that are the result of transparent content negotiation whenever an Accept-Encoding header in the request allows it. When negotiating on the content encoding of a cacheable response, servers MUST add the accept-encoding header name to the Vary header of the response, or add `Vary: *'.
応答の満足しているコード化の交渉はわかりやすい満足している交渉と直交しています。 満足しているコード化が適用されるかもしれない時の間の規則はHTTP/1.1と同じです: サーバは要求におけるAcceptをコード化しているヘッダーがそれを許容するときはいつも、わかりやすい満足している交渉の結果である満足しているエンコード応答がそうするかもしれません。 「キャッシュ-可能」応答の満足しているコード化に関して交渉するとき、サーバは、コード化を受け入れているヘッダー名を応答のVaryヘッダーに加えなければならないか、または'異なってください'を加えなければなりません。 *'.
Holtman & Mutz Experimental [Page 41] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[41ページ]RFC2295
Servers SHOULD always be able to provide unencoded versions of every transparently negotiated response. This means in particular that every variant in the variant list SHOULD at least be available in an unencoded form.
サーバSHOULD、いつもあらゆる透過的に交渉された応答の暗号化されていないバージョンを提供できてください。 これは、異形リストSHOULDのあらゆる異形が暗号化されていないフォームで少なくとも利用可能であることを特に意味します。
Like HTTP/1.1, this specification allows proxies to encode or decode relayed or cached responses on the fly, unless explicitly forbidden by a Cache-Control directive. The encoded or decoded response still contains the same variant as far as transparent content negotiation is concerned. Note that HTTP/1.1 requires proxies to add a Warning header if the encoding of a response is changed.
HTTP/1.1のように、プロキシは、この仕様で、急いでリレーされたかキャッシュされた応答をコード化するか、または解読します、Cache-コントロール指示で明らかに禁じられない場合。 わかりやすい満足している交渉に関する限り、コード化されたか解読された応答はまだ同じ異形を含んでいます。 応答のコード化を変えるならHTTP/1.1が、プロキシがWarningヘッダーを加えるのを必要とすることに注意してください。
11 User agent support for transparent negotiation
11 わかりやすい交渉のユーザエージェントサポート
This section specifies the requirements a user agent needs to satisfy in order to support transparent negotiation. If the user agent contains an internal cache, this cache MUST conform to the rules for proxy caches in section 13.
このセクションはユーザエージェントがわかりやすい交渉をサポートするために満たす必要がある要件を指定します。 ユーザエージェントが内部キャッシュを含むなら、このキャッシュはプロキシキャッシュのためにセクション13で規則に従わなければなりません。
11.1 Handling of responses
11.1 応答の取り扱い
If a list response is received when a resource is accessed, the user agent MUST be able to automatically choose, retrieve, and display the best variant, or display an error message if none of the variants are acceptable.
ユーザエージェントは、最も良い異形を検索して、表示するか、またはリソースがアクセスされているとき、リスト応答が受け取られていて、異形のいずれも許容できないならエラーメッセージを表示するように自動的に選ぶことができなければなりません。
If a choice response is received when a resource is accessed, the usual action is to automatically display the enclosed entity. However, if a remote variant selection algorithm which was enabled could have made a choice different from the choice the local algorithm would make, the user agent MAY apply its local algorithm to any variant list in the response, and automatically retrieve and display another variant if the local algorithm makes an other choice.
リソースがアクセスされているとき、特選している応答が受け取られているなら、普通の動作は自動的に同封の実体を表示することです。 しかしながら、選択が可能にされたリモート異形選択アルゴリズムでローカルのアルゴリズムがする選択と異なるようになったかもしれないなら、ローカルのアルゴリズムが他の選択をするなら、ユーザエージェントは、自動的に別の異形を応答でどんな異形リストにもローカルのアルゴリズムを適用して、検索して、表示するかもしれません。
When receiving a choice response, a user agent SHOULD check if variant resource is a neighboring variant resource of the negotiable resource. If this is not the case, the user agent SHOULD reject the choice response as a probable spoofing attempt and display an error message, for example by internally replacing the choice response with a 502 (bad gateway) response.
特選している応答を受けるとき、異形リソースであるなら、ユーザエージェントSHOULDチェックは交渉可能なリソースの隣接している異形リソースです。 これがそうでないなら、ユーザエージェントSHOULDはありえそうなスプーフィング試みとして特選している応答を拒絶して、エラーメッセージを表示します、例えば、内部的に特選している応答を502(悪いゲートウェイ)応答に取り替えることによって。
11.2 Presentation of a transparently negotiated resource
11.2 透過的に交渉されたリソースのプレゼンテーション
If the user agent is displaying a variant which is not an embedded or inlined object and which is the result of transparent content negotiation, the following requirements apply.
ユーザエージェントが埋め込まれたか不裏打ちされたオブジェクトでなく、わかりやすい満足している交渉の結果である異形を表示しているなら、以下の要件は適用されます。
Holtman & Mutz Experimental [Page 42] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[42ページ]RFC2295
1. The user agent SHOULD allow the user to review a list of all
variants bound to the negotiable resource, and to manually
retrieve another variant if desired. There are two general ways
of providing such a list. First, the information in the
Alternates header of the negotiable resource could be used to
make an annotated menu of variants. Second, the entity included
in a list response of the negotiable resource could be displayed.
Note that a list response can be obtained by doing a GET request
which only has the "trans" directive in the Negotiate header.
1. ユーザエージェントSHOULDはユーザに交渉可能なリソースに縛られたすべての異形のリストを再検討して、望まれているなら、別の異形を手動で検索させます。 そのようなリストを提供する2つの一般的な方法があります。 まず最初に、異形の注釈されたメニューを作るのに交渉可能なリソースのAlternatesヘッダーの情報を使用できました。 2番目に、交渉可能なリソースのリスト応答に実体を含んでいるのを表示できました。 GETをしながら応答を得ることができるリストがどれを要求するかというメモがそうするだけである、「移-、」 Negotiateヘッダーでは、指示です。
2. The user agent SHOULD make available though its user interface
some indication that the resource being displayed is a negotiated
resource instead of a plain resource. It SHOULD also allow the
user to examine the variant list included in the Alternates
header. Such a notification and review mechanism is needed
because of privacy considerations, see section 14.1.
2. ユーザーインタフェースですが、表示されるリソースが何らかの指示ですが、ユーザエージェントSHOULDが利用可能に作る、明瞭なリソースの代わりに交渉されたリソース。 それ、また、SHOULDはユーザにAlternatesヘッダーに含まれていた異形リストを調べさせます。 セクション14.1は、そのような通知とレビューメカニズムがプライバシー問題のために必要であることを見ます。
3. If the user agent shows the URI of the displayed information to
the user, it SHOULD be the negotiable resource URI, not the
variant URI that is shown. This encourages third parties, who
want to refer to the displayed information in their own
documents, to make a hyperlink to the negotiable resource as a
whole, rather than to the variant resource which happens to be
shown. Such correct linking is vital for the interoperability of
content across sites. The user agent SHOULD however also provide
a means for reviewing the URI of the particular variant which is
currently being displayed.
3. エージェントはユーザであるなら表示された情報のURIをユーザに示していて、それはSHOULDです。交渉可能なリソースURI(示される異形URIでない)になってください。 これは、第三者がハイパーリンクをたまたま示される異形リソースにというよりむしろ全体で交渉可能なリソースにするよう奨励します。(その第三者は、それら自身のドキュメントの表示された情報を示したがっています)。 内容の相互運用性に、そのような正しいリンクはサイトの向こう側に重大です。 しかしながら、また、ユーザエージェントSHOULDは現在表示されている特定の異形のURIを見直すための手段を提供します。
4. Similarly, if the user agent stores a reference to the
displayed information for future use, for example in a hotlist,
it SHOULD store the negotiable resource URI, not the variant URI.
4. 同様に、エージェントはユーザであるなら表示された情報の未来の使用の参照を保存します、例えば、ホットリストで、それ。SHOULDは交渉可能なリソースURI(異形URIでない)を保存します。
It is encouraged, but not required, that some of the above functionality is also made available for inlined or embedded objects, and when a variant which was selected manually is being displayed.
奨励されますが、また、不裏打ちされたか埋め込まれたオブジェクトといつ手動で選択された異形を表示しているか間上記の機能性のいくつかを利用可能にするのが必要ではありません。
12 Origin server support for transparent negotiation
12 わかりやすい交渉の発生源サーバサポート
12.1 Requirements
12.1 要件
To implement transparent negotiation on a resource, the origin server MUST be able to send a list response when getting a GET request on the resource. It SHOULD also be able to send appropriate list responses for HEAD requests. When getting a request on a transparently negotiable resource, the origin server MUST NEVER return a response with a 2xx status code or any 3xx status code, except 304, which is not a list, choice, or adhoc response.
リソースに関するGET要求を得るとき、リソースのわかりやすい交渉を実装するために、発生源サーバはリスト応答を送ることができなければなりません。 それ、SHOULD、また、HEAD要求のための適切なリスト応答を送ることができてください。 透過的に交渉可能なリソースに関する要求を得るとき、発生源サーバは2xxステータスコードかどんな3xxステータスコードによる応答も決して返してはいけません、304を除いて。(304は、リストでなくて、また選択でない、またまたはadhoc応答でもありません)。
Holtman & Mutz Experimental [Page 43] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[43ページ]RFC2295
If the request includes a Negotiate header with a "vlist" or "trans" directive, but without any directive which allows the server to select a best variant, a list response MUST ALWAYS be sent, except when the server is performing a server-side override for bug compatibility. If the request includes a Negotiate header with a "vlist" or "guess-small" directive, an Alternates header with the variant list bound to the negotiable resource MUST ALWAYS be sent in any list, choice, or adhoc response, except when the server is performing a server-side override for bug compatibility.
または、要求が"vlist"でNegotiateヘッダーを含んでいる、「移-、」 指示、サーバが選択できる中で異形最も良い指示、いずれのないリスト応答MUST ALWAYSだけを送って、サーバがいつの間、サーバサイドオーバーライドを実行しているかを除いて、互換性を悩ましてください。 要求が"vlist"か「推測小さい」指示でNegotiateヘッダーを含んでいるなら、どんなリストでも異形リストバウンドを交渉可能なリソースMUST ALWAYSに送るAlternatesヘッダー、選択、またはサーバがサーバ側を実行している時以外のadhoc応答がバグのために互換性をくつがえします。
If the Negotiate header allows it, the origin server MAY run a remote variant selection algorithm. If the algorithm has sufficient information to choose a best variant, and if the best variant is a neighboring variant, the origin server MAY return a choice response with this variant.
Negotiateヘッダーがそれを許容するなら、発生源サーバはリモート異形選択アルゴリズムを実行するかもしれません。 アルゴリズムで最も良い異形を選ぶことができるくらいの情報があって、最も良い異形が隣接している異形であるなら、発生源サーバはこの異形がある特選している応答を返すかもしれません。
When getting a request on a transparently negotiable resource from a user agent which does not support transparent content negotiation, the origin server MAY use a custom algorithm to select between sending a list, choice, or adhoc response.
ユーザエージェントからのわかりやすい満足している交渉をサポートしない透過的に交渉可能なリソースに関する要求を得るとき、発生源サーバはリスト、選択、またはadhoc応答を送るとき選択するカスタムアルゴリズムを使用するかもしれません。
The following table summarizes the rules above.
以下のテーブルは上の規則をまとめます。
|Req on |Usr agnt|server- | Response may be: |
|trans neg|capable |side +------+------+------+------+------+
|resource?|of TCN? |override?|list |choice|adhoc |normal|error |
+---------+--------+---------+------+------+------+------+------+
| Yes | Yes | No |always|smt(*)|never |never |always|
+---------+--------+---------+------+------+------+------+------+
| Yes | Yes | Yes |always|always|always|never |always|
+---------+--------+---------+------+------+------+------+------+
| Yes | No | - |always|always|always|never |always|
+---------+--------+---------+------+------+------+------+------+
| No | - | - |never |never |never |always|always|
+---------+--------+---------+------+------+------+------+------+
(*) sometimes, when allowed by the Negotiate request header
|、Reqにオン|Usr agnt|サーバ| 応答は以下の通りです。 | |移-neg|できる|側+------+------+------+------+------+ |リソース?| TCNについて? |オーバーライド?| リスト|選択|adhoc|標準|誤り| +---------+--------+---------+------+------+------+------+------+ | はい| はい| いいえ|いつも|smt(*)|never|never|いつも| +---------+--------+---------+------+------+------+------+------+ | はい| はい| はい|いつも|いつも|いつも|never|いつも| +---------+--------+---------+------+------+------+------+------+ | はい| いいえ| - |いつも|いつも|いつも|never|いつも| +---------+--------+---------+------+------+------+------+------+ | いいえ| - | - |never|never|never|いつも|いつも| +---------+--------+---------+------+------+------+------+------+ 時々Negotiate要求ヘッダーによって許容された(*)いつ
Negotiability is a binary property: a resource is either transparently negotiated, or it is not. Origin servers SHOULD NOT vary the negotiability of a resource, or the variant list bound to that resource, based on the request headers which are received. The variant list and the property of being negotiated MAY however change through time. The Cache-Control header can be used to control the propagation of such time-dependent changes through caches.
流通性は2進の特性です: リソースが透過的に交渉されるか、またはそれはそのように交渉されません。 発生源サーバSHOULD NOTがリソースの流通性を変えるか、または異形リストはそのリソースに付きました、受け取られていている要求ヘッダーに基づいて。 しかしながら、異形リストと交渉される資産は時代を通して変化するかもしれません。 キャッシュを通したそのような時間依存的変化の伝播を制御するのにCache-コントロールヘッダーを使用できます。
It is the responsibility of the author of the negotiable resource to ensure that all resources in the variant list serve the intended content, and that the variant resources do not engage in transparent
異形リストのすべてのリソースが意図している内容に役立って、異形リソースが透明に従事しないのを保証するのは、交渉可能なリソースの作者の責任です。
Holtman & Mutz Experimental [Page 44] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[44ページ]RFC2295
content negotiation themselves.
交渉を自分たちで満足させてください。
12.2 Negotiation on transactions other than GET and HEAD
12.2 GETとHEAD以外のトランザクションの交渉
If a resource is transparently negotiable, this only has an impact on the GET and HEAD transactions on the resource. It is not possible (under this specification) to do transparent content negotiation on the direct result of a POST request.
リソースが透過的に交渉可能であるなら、これはリソースでGETとHEADトランザクションに影響を与えるだけです。 ポストの要求の直接の結果のわかりやすい満足している交渉をするのは可能ではありません(この仕様に基づく)。
However, a POST request can return an unnegotiated 303 (See Other) response which causes the user agent to do a GET request on a second resource. This second resource could then use transparent content negotiation to return an appropriate final response. The figure below illustrates this.
しかしながら、ポストの要求はユーザエージェントが2番目のリソースでGET要求をする非交渉された303(Otherを見る)応答を返すことができます。 そして、この2番目のリソースは、適切な最終的な応答を返すのにわかりやすい満足している交渉を使用するかもしれません。 以下の図はこれを例証します。
Server ______ proxy ______ proxy ______ user
x.org cache cache agent
サーバ______ プロキシ______ プロキシ______ ユーザx.orgキャッシュキャッシュエージェント
< -------------------------------------
| POST http://x.org/cgi/submit
| <form contents in request body>
|
-------------------------------------- >
303 See Other |
Location: http://x.org/result/OK |
|
< -------------------------------------
| GET http://x.org/result/OK
| small Accept- headers
|
able to choose on
behalf of user agent
|
------------------------------------- >
choice response with |
..result/OK.nl variant |
displays OK.nl
<。------------------------------------- | ポスト http://x.org/cgi/submit | 要求本体>の<フォームコンテンツ| -------------------------------------- 303が他であるのを見る>。| 位置: http://x.org/result/OK | | <。------------------------------------- | http://x.org/result/OK を手に入れてください。| 小さいAcceptヘッダー| ユーザエージェントを代表して選ぶことができます。| ------------------------------------- >の特選している応答| ..結果/OK.nl異形| OK.nlを表示します。
See the HTTP/1.1 specification [1] for details on the 303 (See Other) status code. Note that this status code is not understood by some HTTP/1.0 clients.
303(Otherを見る)ステータスコードに関する詳細のためのHTTP/1.1仕様[1]を見てください。 このステータスコードが何人かのHTTP/1.0人のクライアントに解釈されないことに注意してください。
13 Proxy support for transparent negotiation
13 わかりやすい交渉のプロキシサポート
Transparent content negotiation is an extension on top of HTTP/1.x. It is designed to work through any proxy which only implements the HTTP/1.1 specification [1]. If Expires headers are added as discussed in section 10.7, negotiation will also work though proxies
わかりやすい満足している交渉はHTTP/1.xの上の拡大です。 それはどんなプロキシを通したHTTP/1.1仕様が[1]であると実装するだけである仕事に設計されています。 また、もっとも、Expiresヘッダーがセクション10.7で議論するように加えられると、交渉はプロキシを働かせるでしょう。
Holtman & Mutz Experimental [Page 45] RFC 2295 Transparent Content Negotiation March 1998
1998年の満足している交渉行進のときに透明なHoltman&Mutz実験的な[45ページ]RFC2295
which implement HTTP/1.0 [2]. Thus, every HTTP/1.0 or HTTP/1.1 proxy provides support for transparent content negotiation. However, if it is to be claimed that a HTTP/1.x proxy offers transparent content negotiation services, at least one of the specific optimizations below MUST be implemented.
HTTP/1.0[2]を実装します。 したがって、すべてのHTTP/1.0かHTTP/1.1プロキシがわかりやすい満足している交渉のサポートを提供します。 しかしながら、HTTP/1.xプロキシがわかりやすい満足している交渉サービスを提供すると主張されるつもりであるなら、少なくとも以下での特定の最適化の1つを実装しなければなりません。
An HTTP/1.x proxy MUST ONLY optimize (change) the HTTP traffic flowing through it in ways which are explicitly allowed by the specification(s) it conforms to. A proxy which supports transparent content negotiation on top of HTTP/1.x MAY perform the optimizations allowed for by HTTP/1.x. In addition, it MAY perform three additional optimizations, defined below, on the HTTP traffic for transparently negotiated resources and their neighboring variant resources.
HTTP/1.xプロキシはそれを通してそれが従う仕様で明らかに許容されている方法で流れるHTTPトラフィックを最適化するだけでよいです(変えます)。 HTTP/1.xの上のわかりやすい満足している交渉がそうするそれのサポートがHTTP/1.xによって考慮された最適化を実行するプロキシ。 さらに、追加最適化であって、以下で定義されていた状態で3を実行するかもしれません、透過的に交渉されたリソースのためのHTTPトラフィックとそれらの隣接している異形リソースで。
First, when getting a request on a transparently negotiable resource from a user agent which supports transparent content negotiation, the proxy MAY return any cached, fresh list response from that resource, even if the selecting request headers, as specified by the Vary header, do not match.
ユーザエージェントからのわかりやすい満足している交渉をサポートする透過的に交渉可能なリソースに関する要求を得るとき、まず最初に、プロキシはそのリソースからどんなキャッシュされて、新鮮なリスト応答も返すかもしれません、選択が、Varyヘッダーによって指定されるヘッダーが合っていないよう要求しても。
Second, when allowed by the user agent and origin server, a proxy MAY reuse an Alternates header taken from a previous response (section 10.4) to run a remote variant selection algorithm. If the algorithm has sufficient information to choose a best variant, and if the best variant is a neighboring variant, the proxy MAY return a choice response with this variant.
2番目に、ユーザエージェントと発生源サーバによって許容されていると、プロキシはリモート異形選択アルゴリズムを実行するために前の応答(セクション10.4)から連れて行かれたAlternatesヘッダーを再利用するかもしれません。 アルゴリズムで最も良い異形を選ぶことができるくらいの情報があって、最も良い異形が隣接している異形であるなら、プロキシはこの異形がある特選している応答を返すかもしれません。
Third, if a proxy receives a choice response, it MAY extract and cache the normal response embedded therein, as described in section 10.5.
3番目、プロキシが特選している応答を受けるなら、そこに埋め込まれた通常の応答を、抽出して、キャッシュするかもしれません、セクション10.5で説明されるように。
14 Security and privacy considerations
14 セキュリティとプライバシー問題
14.1 Accept- headers revealing personal information
14.1は個人情報を明らかにするヘッダーを受け入れます。
Accept- headers, in particular Accept-Language headers, may reveal information which the user would rather keep private unless it will directly improve the quality of service. For example, a user may not want to send language preferences to sites which do not offer multi- lingual content. The transparent content negotiation mechanism allows user agents to omit sending of the Accept-Language header by default, without adversely affecting the outcome of the negotiation process if transparently negotiated multi-lingual content is accessed.
Holtman & Mutz Experimental [Page 46] RFC 2295 Transparent Content Negotiation March 1998
However, even if Accept- headers are never sent, the automatic selection and retrieval of a variant by a user agent will reveal a preference for this variant to the server. A malicious service author could provide a page with `fake' negotiability on (ethnicity- correlated) languages, with all variants actually being the same English document, as a means of obtaining privacy-sensitive information. Such a plot would however be visible to an alert victim if the list of available variants and their properties is reviewed.
Some additional privacy considerations connected to Accept- headers are discussed in [1].
14.2 Spoofing of responses from variant resources
The caching optimization in section 10.5 gives the implementer of a negotiable resource control over the responses cached for all neighboring variant resources. This is a security problem if a neighboring variant resource belongs to another author. To provide security in this case, the HTTP server will have to filter the Content-Location headers in the choice responses generated by the negotiable resource implementation.
14.3 Security holes revealed by negotiation
Malicious servers could use transparent content negotiation as a means of obtaining information about security holes which may be present in user agents. This is a risk in particular for negotiation on the availability of scripting languages and libraries.
15 Internationalization considerations
This protocol defines negotiation facilities which can be used for the internationalization of web content. For the internationalization of list response bodies (section 10.1), HTTP/1.0 style negotiation (section 4.2) can be used.
16 Acknowledgments
Work on HTTP content negotiation has been done since at least 1993. The authors are unable to trace the origin of many of the ideas incorporated in this document. Many members of the HTTP working group have contributed to the negotiation model in this specification. The authors wish to thank the individuals who have commented on earlier versions of this document, including Brian Behlendorf, Daniel DuBois, Martin J. Duerst, Roy T. Fielding, Jim Gettys, Yaron Goland, Dirk van Gulik, Ted Hardie, Graham Klyne, Scott Lawrence, Larry Masinter, Jeffrey Mogul, Henrik Frystyk Nielsen, Frederick G.M. Roeber, Paul Sutton, and Klaus Weide and Mark Wood.
Holtman & Mutz Experimental [Page 47] RFC 2295 Transparent Content Negotiation March 1998
17 References
[1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and
T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
2068, January 1997.
[2] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[3] Holtman, K., and A. Mutz, "HTTP Remote Variant Selection
Algorithm -- RVSA/1.0", RFC 2296, March 1998.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
10646", RFC 2044, October 1996.
18 Authors' Addresses
Koen Holtman Technische Universiteit Eindhoven Postbus 513 Kamer HG 6.57 5600 MB Eindhoven (The Netherlands)
EMail: koen@win.tue.nl
Andrew H. Mutz Hewlett-Packard Company 1501 Page Mill Road 3U-3 Palo Alto CA 94304, USA
Fax +1 415 857 4691 EMail: mutz@hpl.hp.com
Holtman & Mutz Experimental [Page 48] RFC 2295 Transparent Content Negotiation March 1998
19 Appendix: Example of a local variant selection algorithm
A negotiating user agent will choose the best variant from a variant list with a local variant selection algorithm. This appendix contains an example of such an algorithm.
The inputs of the algorithm are a variant list from an Alternates header, and an agent-side configuration database, which contains
- the feature set of the current request,
- a collection of quality values assigned to media types,
languages, and charsets for the current request, following the
model of the corresponding HTTP/1.1 [1] Accept- headers,
- a table which lists `forbidden' combinations of media types and
charsets, i.e. combinations which cannot be displayed because of
some internal user agent limitation.
The output of the algorithm is either the best variant, or the conclusion that none of the variants are acceptable.
19.1 Computing overall quality values
As a first step in the local variant selection algorithm, the overall qualities associated with all variant descriptions in the list are computed.
The overall quality Q of a variant description is the value
Q = round5( qs * qt * qc * ql * qf * qa )
where rounds5 is a function which rounds a floating point value to 5 decimal places after the point. It is assumed that the user agent can run on multiple platforms: the rounding function makes the algorithm independent of the exact characteristics of the underlying floating point hardware.
The factors qs, qt, qc, ql, qf, and qa are determined as follows.
qs Is the source quality factor in the variant description.
qt The media type quality factor is 1 if there is no type
attribute in the variant description. Otherwise, it is the
quality value assigned to this type by the configuration
database. If the database does not assign a value, then the
factor is 0.
Holtman & Mutz Experimental [Page 49] RFC 2295 Transparent Content Negotiation March 1998
qc The charset quality factor is 1 if there is no charset
attribute in the variant description. Otherwise, it is the
quality value assigned to this charset by the configuration
database. If the database does not assign a value, then the
factor is 0.
ql The language quality factor is 1 if there is no language
attribute in the variant description. Otherwise, it is the
highest quality value the configuration database assigns to any
of the languages listed in the language attribute. If the
database does not assign a value to any of the languages
listed, then the factor is 0.
qf The features quality factor is 1 if there is no features
attribute in the variant description. Otherwise, it is the
quality degradation factor computed for the features attribute
using the feature set of the current request.
qa The quality adjustment factor is 0 if the variant description
lists a media type - charset combination which is `forbidden'
by the table, and 1 otherwise.
As an example, if a variant list contains the variant description
{"paper.2" 0.7 {type text/html} {language fr}}
and if the configuration database contains the quality value assignments
types: text/html;q=1.0, type application/postscript;q=0.8
languages: en;q=1.0, fr;q=0.5
then the local variant selection algorithm will compute the overall quality for the variant description as follows:
{"paper.2" 0.7 {type text/html} {language fr}}
| | |
| | |
V V V
round5 ( 0.7 * 1.0 * 0.5 ) = 0.35000
With same configuration database, the variant list
{"paper.1" 0.9 {type text/html} {language en}},
{"paper.2" 0.7 {type text/html} {language fr}},
{"paper.3" 1.0 {type application/postscript} {language en}}
would yield the following computations:
Holtman & Mutz Experimental [Page 50] RFC 2295 Transparent Content Negotiation March 1998
round5 ( qs * qt * qc * ql * qf * qa ) = Q
--- --- --- --- --- ---
paper.1: 0.9 * 1.0 * 1.0 * 1.0 * 1.0 * 1.0 = 0.90000
paper.1: 0.7 * 1.0 * 1.0 * 0.5 * 1.0 * 1.0 = 0.35000
paper.3: 1.0 * 0.8 * 1.0 * 1.0 * 1.0 * 1.0 = 0.80000
19.2 Determining the result
Using all computed overall quality values, the end result of the local variant selection algorithm is determined as follows.
If all overall quality values are 0, then the best variant is the fallback variant, if there is one in the list, else the result is the conclusion that none of the variants are acceptable.
If at least one overall quality value is greater than 0, then the best variant is the variant which has the description with the highest overall quality value, or, if there are multiple variant descriptions which share the highest overall quality value, the variant of the first variant description in the list which has this highest overall quality value.
19.3 Ranking dimensions
Consider the following variant list:
{"paper.greek" 1.0 {language el} {charset ISO-8859-7}},
{"paper.english" 1.0 {language en} {charset ISO-8859-1}}
It could be the case that the user prefers the language "el" over "en", while the user agent can render "ISO-8859-1" better than "ISO- 8859-7". The result is that in the language dimension, the first variant is best, while the second variant is best in the charset dimension. In this situation, it would be preferable to choose the first variant as the best variant: the user settings in the language dimension should take precedence over the hard-coded values in the charset dimension.
To express this ranking between dimensions, the user agent configuration database should have a higher spread in the quality values for the language dimension than for the charset dimension. For example, with
languages: el;q=1.0, en-gb;q=0.7, en;q=0.6, da;q=0, ...
charsets: ISO-8859-1;q=1.0, ISO-8859-7;q=0.95,
ISO-8859-5;q=0.97, unicode-1-1;q=0, ...
Holtman & Mutz Experimental [Page 51] RFC 2295 Transparent Content Negotiation March 1998
the first variant will have an overall quality of 0.95000, while the second variant will have an overall quality 0.70000. This makes the first variant the best variant.
20 Appendix: feature negotiation examples
This appendix contains examples of the use of feature tags in variant descriptions. The tag names used here are examples only, they do not in general reflect the tag naming scheme proposed in [4].
20.1 Use of feature tags
Feature tags can be used in variant lists to express the quality degradation associated with the presence or absence of certain features. One example is
{"index.html.plain" 0.7 },
{"index.html" 1.0 {features tables frames}}
Here, the "{features tables frames}" part expresses that index.html
uses the features tagged as tables and frames. If these features are
absent, the overall quality of index.html degrades to 0. Another
example is
{"home.graphics" 1.0 {features !textonly}},
{"home.textonly" 0.7 }
where the "{features !textonly}" part expresses that home.graphics
requires the absence of the textonly feature. If the feature is
present, the overall quality of home.graphics degrades to 0.
The absence of a feature need not always degrade the overall quality to 0. In the example
{"x.html.1" 1.0 {features fonts;-0.7}}
the absence of the fonts feature degrades the quality with a factor of 0.7. Finally, in the example
{"y.html" 1.0 {features [blebber wolx] }}
The "[blebber wolx]" expresses that y.html requires the presence of the blebber feature or the wolx feature. This construct can be used in a number of cases:
1. blebber and wolx actually tag the same feature, but they were
registered by different people, and some user agents say they
support blebber while others say they support wolx.
Holtman & Mutz Experimental [Page 52] RFC 2295 Transparent Content Negotiation March 1998
2. blebber and wolx are HTML tags of different vendors which
implement the same functionality, and which are used together in
y.html without interference.
3. blebber and wolx are HTML tags of different vendors which
implement the same functionality, and y.html uses the tags in a
conditional HTML construct.
4. blebber is a complicated HTML tag with only a sketchy
definition, implemented by one user agent vendor, and wolx
indicates implementation of a well-defined subset of the blebber
tag by some other vendor(s). y.html uses only this well-defined
subset.
20.2 Use of numeric feature tags
As an example of negotiation in a numeric area, the following variant list describes four variants with title graphics designed for increasing screen widths:
{"home.pda" 1.0 {features screenwidth=[-199] }},
{"home.narrow" 1.0 {features screenwidth=[200-599] }},
{"home.normal" 1.0 {features screenwidth=[600-999] }},
{"home.wide" 1.0 {features screenwidth=[1000-] }},
{"home.normal"}
The last element of the list specifies a safe default for user agents which do not implement screen width negotiation. Such user agents will reject the first four variants as unusable, as they seem to rely on a feature which they do not understand.
20.3 Feature tag design
When designing a new feature tag, it is important to take into account that existing user agents, which do not recognize the new tag will treat the feature as absent. In general, a new feature tag needs to be designed in such a way that absence of the tag is the default case which reflects current practice. If this design principle is ignored, the resulting feature tag will generally be unusable.
As an example, one could try to support negotiation between monochrome and color content by introducing a `color' feature tag, the presence of which would indicate the capability to display color graphics. However, if this new tag is used in a variant list, for example
{"rainbow.gif" 1.0 {features color} }
Holtman & Mutz Experimental [Page 53] RFC 2295 Transparent Content Negotiation March 1998
{"rainbow.mono.gif" 0.6 {features !color}}
then existing user agents, which would not recognize the color tag, would all display the monochrome rainbow. The color tag is therefore unusable in situations where optimal results for existing user agents are desired. To provide for negotiation in this area, one must introduce a `monochrome' feature tag; its presence indicates that the user agent can only render (or the user prefers to view) monochrome graphics.
21 Appendix: origin server implementation considerations
21.1 Implementation with a CGI script
Transparent content negotiation has been designed to allow a broad range of implementation options at the origin server side. A very minimal implementation can be done using the CGI interface. The CGI script below is an example.
#!/bin/sh
cat - <<'blex'
TCN: list
Alternates: {"stats.tables.html" 1.0 {type text/html} {features
tables}}, {"stats.html" 0.8 {type text/html}}, {"stats.ps" 0.95
{type application/postscript}}
Vary: *
Content-Type: text/html
<title>Multiple Choices for Web Statistics</title>
<h2>Multiple Choices for Web Statistics:</h2>
<ul>
<li><a href=stats.tables.html>Version with HTML tables</a>
<p>
<li><a href=stats.html>Version without HTML tables</a>
<p>
<li><a href=stats.ps>Postscript version</a>
</ul>
blex
The Alternates header in the above script must be read as a single line. The script always generates a list response with the 200 (OK) code, which ensures compatibility with non-negotiating HTTP/1.0 agents.
Holtman & Mutz Experimental [Page 54] RFC 2295 Transparent Content Negotiation March 1998
21.2 Direct support by HTTP servers
Sophisticated HTTP servers could make a transparent negotiation module available to content authors. Such a module could incorporate a remote variant selection algorithm and an implementation of the algorithm for generating choice responses (section 10.2). The definition of interfaces to such modules is beyond the scope of this specification.
21.3 Web publishing tools
Web publishing tools could automatically generate several variants of a document (for example the original TeX version, a HTML version with tables, a HTML version without tables, and a Postscript version), together with an appropriate variant list in the interface format of a HTTP server transparent negotiation module. This would allow documents to be published as transparently negotiable resources.
22 Appendix: Example of choice response construction
The following is an example of the construction of a choice response by a proxy cache which supports HTTP/1.1 and transparent content negotiation. The use of the HTTP/1.1 conditional request mechanisms is also shown.
Assume that a user agent has cached a variant list with the validator "1234" for the negotiable resource http://x.org/paper. Also assume that it has cached responses from two neighboring variants, with the entity tags "gonkyyyy" and W/"a;b". Assume that all three user agent cache entries are stale: they would need to be revalidated before the user agent can use them. If http://x.org/paper accessed in this situation, the user agent could send the following request to its proxy cache:
GET /paper HTTP/1.1
Host: x.org
User-Agent: WuxtaWeb/2.4
Negotiate: 1.0
Accept: text/html, application/postscript;q=0.4, */*
Accept-Language: en
If-None-Match: "gonkyyyy;1234", W/"a;b;1234"
Assume that the proxy cache has cached the same three items as the user agent, but that it has revalidated the variant list 8000 seconds ago, so that the list is still fresh for the proxy. This means that the proxy can run a remote variant selection algorithm on the list and the incoming request.
Holtman & Mutz Experimental [Page 55] RFC 2295 Transparent Content Negotiation March 1998
Assume that the remote algorithm is able to choose paper.html.en as the best variant. The proxy can now construct a choice response, using the algorithm in section 10.2. In steps 1 and 2 of the algorithm, the proxy can construct the following conditional request on the best variant, and send it to the origin server:
GET /paper.html.en HTTP/1.1
Host: x.org
User-Agent: WuxtaWeb/2.4
Negotiate: 1.0
Accept: text/html, application/postscript;q=0.4, */*
Accept-Language: en
If-None-Match: "gonkyyyy", W/"a;b"
Via: 1.1 fred
On receipt of the response
HTTP/1.1 304 Not Modified
Date: Tue, 11 Jun 1996 20:05:31 GMT
Etag: "gonkyyyy"
from the origin server, the proxy can use its freshly revalidated paper.html.en cache entry to expand the response to a non-304 response:
HTTP/1.1 200 OK
Date: Tue, 11 Jun 1996 20:05:31 GMT
Content-Type: text/html
Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT
Content-Length: 5327
Cache-control: max-age=604800
Etag: "gonkyyyy"
Via: 1.1 fred
Age: 0
<title>A paper about ....
Using this 200 response, the proxy can construct a choice response in step 4 of the algorithm:
HTTP/1.1 200 OK
Date: Tue, 11 Jun 1996 20:05:31 GMT
TCN: choice
Content-Type: text/html
Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT
Content-Length: 5327
Cache-control: max-age=604800
Content-Location: paper.html.en
Holtman & Mutz Experimental [Page 56] RFC 2295 Transparent Content Negotiation March 1998
Alternates: {"paper.html.en" 0.9 {type text/html} {language en}},
{"paper.html.fr" 0.7 {type text/html} {language fr}},
{"paper.ps.en" 1.0 {type application/postscript}
{language en}}
Etag: "gonkyyyy;1234"
Vary: negotiate, accept, accept-language
Expires: Thu, 01 Jan 1980 00:00:00 GMT
Via: 1.1 fred
Age: 8000
<title>A paper about ....
The choice response can subsequently be shortened to a 304 response, because of the If-None-Match header in the original request from the user agent. Thus, the proxy can finally return
HTTP/1.1 304 Not Modified
Date: Tue, 11 Jun 1996 20:05:31 GMT
Etag: "gonkyyyy;1234"
Content-Location: paper.html.en
Vary: negotiate, accept, accept-language
Expires: Thu, 01 Jan 1980 00:00:00 GMT
Via: 1.1 fred
Age: 8000
to the user agent.
Holtman & Mutz Experimental [Page 57] RFC 2295 Transparent Content Negotiation March 1998
23 Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Holtman & Mutz Experimental [Page 58]
一覧
スポンサーリンク
