From 20b9683327326c2f563e29a8011af85459ba83b2 Mon Sep 17 00:00:00 2001 From: Yoshiki Hayashi Date: Fri, 12 Jul 2002 11:16:16 +0000 Subject: [PATCH] New Japanese translation. Submitted by: Hiroaki KAWAI Reviewed by: Yoshiki Hayashi git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@96025 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/content-negotiation.html | 622 ------------------ docs/manual/content-negotiation.html.ja.jis | 659 ++++++++++++++++++++ 2 files changed, 659 insertions(+), 622 deletions(-) delete mode 100644 docs/manual/content-negotiation.html create mode 100644 docs/manual/content-negotiation.html.ja.jis diff --git a/docs/manual/content-negotiation.html b/docs/manual/content-negotiation.html deleted file mode 100644 index 0f4e03ce31..0000000000 --- a/docs/manual/content-negotiation.html +++ /dev/null @@ -1,622 +0,0 @@ - - - - - - - Apache Content Negotiation - - - - - - -

Content Negotiation

- -

Apache's supports content negotiation as described in - the HTTP/1.1 specification. It can choose the best - representation of a resource based on the browser-supplied - preferences for media type, languages, character set and - encoding. It also implements a couple of features to give - more intelligent handling of requests from browsers that send - incomplete negotiation information.

- -

Content negotiation is provided by the mod_negotiation module, - which is compiled in by default.

-
- -

About Content Negotiation

- -

A resource may be available in several different - representations. For example, it might be available in - different languages or different media types, or a combination. - One way of selecting the most appropriate choice is to give the - user an index page, and let them select. However it is often - possible for the server to choose automatically. This works - because browsers can send as part of each request information - about what representations they prefer. For example, a browser - could indicate that it would like to see information in French, - if possible, else English will do. Browsers indicate their - preferences by headers in the request. To request only French - representations, the browser would send

-
-  Accept-Language: fr
-
- -

Note that this preference will only be applied when there is - a choice of representations and they vary by language.

- -

As an example of a more complex request, this browser has - been configured to accept French and English, but prefer - French, and to accept various media types, preferring HTML over - plain text or other text types, and preferring GIF or JPEG over - other media types, but also allowing any other media type as a - last resort:

-
-  Accept-Language: fr; q=1.0, en; q=0.5
-  Accept: text/html; q=1.0, text/*; q=0.8, image/gif; q=0.6,
-        image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1
-
- Apache supports 'server driven' content negotiation, as - defined in the HTTP/1.1 specification. It fully supports the - Accept, Accept-Language, Accept-Charset and Accept-Encoding - request headers. Apache also supports 'transparent' - content negotiation, which is an experimental negotiation - protocol defined in RFC 2295 and RFC 2296. It does not offer - support for 'feature negotiation' as defined in these RFCs. - -

A resource is a conceptual entity - identified by a URI (RFC 2396). An HTTP server like Apache - provides access to representations of the - resource(s) within its namespace, with each representation in - the form of a sequence of bytes with a defined media type, - character set, encoding, etc. Each resource may be associated - with zero, one, or more than one representation at any given - time. If multiple representations are available, the resource - is referred to as negotiable and each of its - representations is termed a variant. The ways - in which the variants for a negotiable resource vary are called - the dimensions of negotiation.

- -

Negotiation in Apache

- -

In order to negotiate a resource, the server needs to be - given information about each of the variants. This is done in - one of two ways:

- - - -

Using a type-map file

- -

A type map is a document which is associated with the - handler named type-map (or, for - backwards-compatibility with older Apache configurations, the - mime type application/x-type-map). Note that to - use this feature, you must have a handler set in the - configuration that defines a file suffix as - type-map; this is best done with a

-
-  AddHandler type-map .var
-
- in the server configuration file. - -

Type map files should have the same name as the resource - which they are describing, and have an entry for each available - variant; these entries consist of contiguous HTTP-format header - lines. Entries for different variants are separated by blank - lines. Blank lines are illegal within an entry. It is - conventional to begin a map file with an entry for the combined - entity as a whole (although this is not required, and if - present will be ignored). An example map file is shown below. - This file would be named foo.var, as it describes - a resource named foo.

-
-  URI: foo
-
-  URI: foo.en.html
-  Content-type: text/html
-  Content-language: en
-
-  URI: foo.fr.de.html
-  Content-type: text/html;charset=iso-8859-2
-  Content-language: fr, de
-
- Note also that a typemap file will take precedence over the - filename's extension, even when Multiviews is on. If the - variants have different source qualities, that may be indicated - by the "qs" parameter to the media type, as in this picture - (available as jpeg, gif, or ASCII-art): -
-  URI: foo
-
-  URI: foo.jpeg
-  Content-type: image/jpeg; qs=0.8
-
-  URI: foo.gif
-  Content-type: image/gif; qs=0.5
-
-  URI: foo.txt
-  Content-type: text/plain; qs=0.01
-
- -

qs values can vary in the range 0.000 to 1.000. Note that - any variant with a qs value of 0.000 will never be chosen. - Variants with no 'qs' parameter value are given a qs factor of - 1.0. The qs parameter indicates the relative 'quality' of this - variant compared to the other available variants, independent - of the client's capabilities. For example, a jpeg file is - usually of higher source quality than an ascii file if it is - attempting to represent a photograph. However, if the resource - being represented is an original ascii art, then an ascii - representation would have a higher source quality than a jpeg - representation. A qs value is therefore specific to a given - variant depending on the nature of the resource it - represents.

- -

The full list of headers recognized is available in the mod_negotation - documentation.

- - -

Multiviews

- -

MultiViews is a per-directory option, meaning - it can be set with an Options directive within a - <Directory>, <Location> - or <Files> section in - access.conf, or (if AllowOverride is - properly set) in .htaccess files. Note that - Options All does not set MultiViews; - you have to ask for it by name.

- -

The effect of MultiViews is as follows: if the - server receives a request for /some/dir/foo, if - /some/dir has MultiViews enabled, and - /some/dir/foo does not exist, then the - server reads the directory looking for files named foo.*, and - effectively fakes up a type map which names all those files, - assigning them the same media types and content-encodings it - would have if the client had asked for one of them by name. It - then chooses the best match to the client's requirements.

- -

MultiViews may also apply to searches for the - file named by the DirectoryIndex directive, if the - server is trying to index a directory. If the configuration - files specify

-
-  DirectoryIndex index
-
- then the server will arbitrate between index.html - and index.html3 if both are present. If neither - are present, and index.cgi is there, the server - will run it. - -

If one of the files found when reading the directory does not - have an extension recognized by mod_mime to designate - its Charset, Content-Type, Language, or Encoding, then the result - depends on the setting of the MultiViewsMatch - directive. This directive determines whether handlers, filters, - and other extension types can participate in MultiViews - negotiation.

- -

The Negotiation Methods

- After Apache has obtained a list of the variants for a given - resource, either from a type-map file or from the filenames in - the directory, it invokes one of two methods to decide on the - 'best' variant to return, if any. It is not necessary to know - any of the details of how negotiation actually takes place in - order to use Apache's content negotiation features. However the - rest of this document explains the methods used for those - interested. - -

There are two negotiation methods:

- -
    -
  1. Server driven negotiation with the Apache - algorithm is used in the normal case. The Apache - algorithm is explained in more detail below. When this - algorithm is used, Apache can sometimes 'fiddle' the quality - factor of a particular dimension to achieve a better result. - The ways Apache can fiddle quality factors is explained in - more detail below.
  2. - -
  3. Transparent content negotiation is used - when the browser specifically requests this through the - mechanism defined in RFC 2295. This negotiation method gives - the browser full control over deciding on the 'best' variant, - the result is therefore dependent on the specific algorithms - used by the browser. As part of the transparent negotiation - process, the browser can ask Apache to run the 'remote - variant selection algorithm' defined in RFC 2296.
  4. -
- -

Dimensions of Negotiation

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
DimensionNotes
Media TypeBrowser indicates preferences with the Accept header - field. Each item can have an associated quality factor. - Variant description can also have a quality factor (the - "qs" parameter).
LanguageBrowser indicates preferences with the Accept-Language - header field. Each item can have a quality factor. Variants - can be associated with none, one or more than one - language.
EncodingBrowser indicates preference with the Accept-Encoding - header field. Each item can have a quality factor.
CharsetBrowser indicates preference with the Accept-Charset - header field. Each item can have a quality factor. Variants - can indicate a charset as a parameter of the media - type.
- -

Apache Negotiation Algorithm

- -

Apache can use the following algorithm to select the 'best' - variant (if any) to return to the browser. This algorithm is - not further configurable. It operates as follows:

- -
    -
  1. First, for each dimension of the negotiation, check the - appropriate Accept* header field and assign a - quality to each variant. If the Accept* header for - any dimension implies that this variant is not acceptable, - eliminate it. If no variants remain, go to step 4.
  2. - -
  3. - Select the 'best' variant by a process of elimination. Each - of the following tests is applied in order. Any variants - not selected at each test are eliminated. After each test, - if only one variant remains, select it as the best match - and proceed to step 3. If more than one variant remains, - move on to the next test. - -
      -
    1. Multiply the quality factor from the Accept header - with the quality-of-source factor for this variant's - media type, and select the variants with the highest - value.
    2. - -
    3. Select the variants with the highest language quality - factor.
    4. - -
    5. Select the variants with the best language match, - using either the order of languages in the - Accept-Language header (if present), or else the order of - languages in the LanguagePriority directive - (if present).
    6. - -
    7. Select the variants with the highest 'level' media - parameter (used to give the version of text/html media - types).
    8. - -
    9. Select variants with the best charset media - parameters, as given on the Accept-Charset header line. - Charset ISO-8859-1 is acceptable unless explicitly - excluded. Variants with a text/* media type - but not explicitly associated with a particular charset - are assumed to be in ISO-8859-1.
    10. - -
    11. Select those variants which have associated charset - media parameters that are not ISO-8859-1. If - there are no such variants, select all variants - instead.
    12. - -
    13. Select the variants with the best encoding. If there - are variants with an encoding that is acceptable to the - user-agent, select only these variants. Otherwise if - there is a mix of encoded and non-encoded variants, - select only the unencoded variants. If either all - variants are encoded or all variants are not encoded, - select all variants.
    14. - -
    15. Select the variants with the smallest content - length.
    16. - -
    17. Select the first variant of those remaining. This - will be either the first listed in the type-map file, or - when variants are read from the directory, the one whose - file name comes first when sorted using ASCII code - order.
    18. -
    -
  4. - -
  5. The algorithm has now selected one 'best' variant, so - return it as the response. The HTTP response header Vary is - set to indicate the dimensions of negotiation (browsers and - caches can use this information when caching the resource). - End.
  6. - -
  7. To get here means no variant was selected (because none - are acceptable to the browser). Return a 406 status (meaning - "No acceptable representation") with a response body - consisting of an HTML document listing the available - variants. Also set the HTTP Vary header to indicate the - dimensions of variance.
  8. -
- -

Fiddling with Quality - Values

- -

Apache sometimes changes the quality values from what would - be expected by a strict interpretation of the Apache - negotiation algorithm above. This is to get a better result - from the algorithm for browsers which do not send full or - accurate information. Some of the most popular browsers send - Accept header information which would otherwise result in the - selection of the wrong variant in many cases. If a browser - sends full and correct information these fiddles will not be - applied.

- -

Media Types and Wildcards

- -

The Accept: request header indicates preferences for media - types. It can also include 'wildcard' media types, such as - "image/*" or "*/*" where the * matches any string. So a request - including:

-
-  Accept: image/*, */*
-
- would indicate that any type starting "image/" is acceptable, - as is any other type (so the first "image/*" is redundant). - Some browsers routinely send wildcards in addition to explicit - types they can handle. For example: -
-  Accept: text/html, text/plain, image/gif, image/jpeg, */*
-
- The intention of this is to indicate that the explicitly listed - types are preferred, but if a different representation is - available, that is ok too. However under the basic algorithm, - as given above, the */* wildcard has exactly equal preference - to all the other types, so they are not being preferred. The - browser should really have sent a request with a lower quality - (preference) value for *.*, such as: -
-  Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01
-
- The explicit types have no quality factor, so they default to a - preference of 1.0 (the highest). The wildcard */* is given a - low preference of 0.01, so other types will only be returned if - no variant matches an explicitly listed type. - -

If the Accept: header contains no q factors at all, - Apache sets the q value of "*/*", if present, to 0.01 to - emulate the desired behavior. It also sets the q value of - wildcards of the format "type/*" to 0.02 (so these are - preferred over matches against "*/*". If any media type on the - Accept: header contains a q factor, these special values are - not applied, so requests from browsers which send the - correct information to start with work as expected.

- -

Language Negotiation Exceptions

- -

New in Apache 2.0, some exceptions have been added to the - negotiation algorithm to allow graceful fallback when language - negotiation fails to find a match.

- -

When a client requests a page on your server, but the server - cannot find a single page that matches the Accept-language sent by - the browser, the server will return either a "No Acceptable - Variant" or "Multiple Choices" response to the client. To avoid - these error messages, it is possible to configure Apache to ignore - the Accept-language in these cases and provide a document that - does not explictly match the client's request. The ForceLanguagePriority - directive can be used to override one or both of these error - messages and subsitute the servers judgement in the form of the LanguagePriority - directive.

- -

The server will also attempt to match language-subsets when no - other match can be found. For example, if a client requests - documents with the language en-GB for British - English, the server is not normally allowed by the HTTP/1.1 - standard to match that against a document that is marked as simply - en. (Note that it is almost surely a configuration - error to include en-GB and not en in the - Accept-Language header, since it is very unlikely that a reader - understands British English, but doesn't understand English in - general. Unfortunately, many current clients have default - configurations that resemble this.) However, if no other language - match is possible and the server is about to return a "No - Acceptable Variants" error or fallback to the - LanguagePriority, the server will ignore the subset - specification and match en-GB against en - documents. Implicitly, Apache will add the parent language to - the client's acceptable language list with a very low quality - value. But note that if the client requests "en-GB; qs=0.9, fr; - qs=0.8", and the server has documents designated "en" and "fr", - then the "fr" document will be returned. This is necessary to - maintain compliance with the HTTP/1.1 specification and to work - effectively with properly configured clients.

- - -

Extensions to Transparent Content Negotiation

- Apache extends the transparent content negotiation protocol - (RFC 2295) as follows. A new {encoding ..} element - is used in variant lists to label variants which are available - with a specific content-encoding only. The implementation of - the RVSA/1.0 algorithm (RFC 2296) is extended to recognize - encoded variants in the list, and to use them as candidate - variants whenever their encodings are acceptable according to - the Accept-Encoding request header. The RVSA/1.0 implementation - does not round computed quality factors to 5 decimal places - before choosing the best variant. - -

Note on hyperlinks and naming conventions

- -

If you are using language negotiation you can choose between - different naming conventions, because files can have more than - one extension, and the order of the extensions is normally - irrelevant (see the mod_mime documentation - for details).

- -

A typical file has a MIME-type extension (e.g., - html), maybe an encoding extension (e.g., - gz), and of course a language extension - (e.g., en) when we have different - language variants of this file.

- -

Examples:

- - - -

Here some more examples of filenames together with valid and - invalid hyperlinks:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
FilenameValid hyperlinkInvalid hyperlink
foo.html.enfoo
- foo.html
-
foo.en.htmlfoofoo.html
foo.html.en.gzfoo
- foo.html
foo.gz
- foo.html.gz
foo.en.html.gzfoofoo.html
- foo.html.gz
- foo.gz
foo.gz.html.enfoo
- foo.gz
- foo.gz.html
foo.html
foo.html.gz.enfoo
- foo.html
- foo.html.gz
foo.gz
- -

Looking at the table above you will notice that it is always - possible to use the name without any extensions in an hyperlink - (e.g., foo). The advantage is that you - can hide the actual type of a document rsp. file and can change - it later, e.g., from html to - shtml or cgi without changing any - hyperlink references.

- -

If you want to continue to use a MIME-type in your - hyperlinks (e.g. foo.html) the language - extension (including an encoding extension if there is one) - must be on the right hand side of the MIME-type extension - (e.g., foo.html.en).

- -

Note on Caching

- -

When a cache stores a representation, it associates it with - the request URL. The next time that URL is requested, the cache - can use the stored representation. But, if the resource is - negotiable at the server, this might result in only the first - requested variant being cached and subsequent cache hits might - return the wrong response. To prevent this, Apache normally - marks all responses that are returned after content negotiation - as non-cacheable by HTTP/1.0 clients. Apache also supports the - HTTP/1.1 protocol features to allow caching of negotiated - responses.

- -

For requests which come from a HTTP/1.0 compliant client - (either a browser or a cache), the directive - CacheNegotiatedDocs can be used to allow caching of - responses which were subject to negotiation. This directive can - be given in the server config or virtual host, and takes no - arguments. It has no effect on requests from HTTP/1.1 clients. - -

More Information

- -

For more information about content negotiation, see Alan - J. Flavell's Language - Negotiation Notes. But note that this document may not be - updated to include changes in Apache 2.0.

- - - - - diff --git a/docs/manual/content-negotiation.html.ja.jis b/docs/manual/content-negotiation.html.ja.jis new file mode 100644 index 0000000000..f861f592f4 --- /dev/null +++ b/docs/manual/content-negotiation.html.ja.jis @@ -0,0 +1,659 @@ + + + + + + + Apache コンテントネゴシエーション + + + + + + + +

コンテントネゴシエーション

+ +

Apache は HTTP/1.1 の規格に記述されているコンテントネゴシエーションを + サポートしています。 + ブラウザにより提供されたメディアタイプ、 + 言語、文字セット、エンコーディングの優先傾向に基づいて、 + 最適なリソースの表現を選択できます。 + また、不完全なネゴシエーション情報を送ってくるブラウザからのリクエストを + もっと賢く取り扱えるよう、いくつか機能も実装してあります。

+ +

コンテントネゴシエーションは mod_negotiation + モジュールにより + 提供されていて、デフォルトで組み込まれています。

+
+ +

コンテントネゴシエーションについて

+ +

リソースは、幾つか異なった表現で利用できる場合があります。 + 例えば、異なる言語や異なるメディアタイプ、 + またはそれらの組み合わせで利用できるかも知れません。 + もっとも適した選択をする方法の一つには、インデックスページを + ユーザに見せて、ユーザに選んでもらう方法があります。 + しかし、サーバが自動的に選ぶことができる場合が多くあります。 + これは、ブラウザがリクエスト情報毎の情報の一部に、 + どの表現を嗜好するかを送ることで動作しています。 + 例えばブラウザは、可能ならフランス語で情報を見たい、 + 不可能ならその代わりに英語でもよいと、 + 自分の嗜好を知らせることができます。 + ブラウザはリクエストのヘッダで自分の優先傾向を知らせます。 + フランス語のみの表現を要求する場合は、ブラウザは次を送ります。

+
+  Accept-Language: fr
+
+ +

この優先傾向は、選択可能な表現が存在して、 + 言語によって様々な表現がある場合にのみ適用される + ということに注意してください。

+ +

もっと複雑なリクエストの例を挙げましょう。 + このブラウザはフランス語と英語を受け付ける、しかしフランス語を好む、 + そして様々なメディアタイプを受け付けるが、 + プレインテキストや他のタイプよりは HTML を好む、 + 他のメディアタイプよりは GIF や JPEG を好む、しかし最終手段として + 他のメディアタイプも受け付ける、と設定されています。

+
+  Accept-Language: fr; q=1.0, en; q=0.5
+  Accept: text/html; q=1.0, text/*; q=0.8, image/gif; q=0.6,
+        image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1
+
+ Apache は HTTP/1.1 規格で定義されている 'server + driven' コンテントネゴシエーションをサポートしています。 + Accept, Accept-Language, Accept-Charset, Accept-Encoding + リクエストヘッダを完全にサポートしています。Apache は + 'transparent' コンテントネゴシエーションもサポートしていますが、 + これは RFC 2295 と RFC 2296 で定義されている実験的な + ネゴシエーションプロトコルです。 + これらの RFCで定義されている 'feature negotiation' + はサポートしていません。 + +

リソースとは URI + で特定される概念上のもののことです (RFC 2396)。 Apache + のような HTTP サーバは、その名前空間の中での + リソースの表現へのアクセスを提供します。 + それぞれの表現は + 定義されたメディアタイプ、文字セット、エンコーディング等の + 付属した、バイト列の形式です。 + それぞれのリソースはある時点で 0 個、1 個、それ以上の表現と + 関連付けられる可能性があります。複数の表現が利用できる場合は、 + リソースはネゴシエーション可能であるとされ、 + 個々の表現は variant と呼ばれます。 + ネゴシエーション可能なリソースの variant が異なる、 + その状態を指して、 + ネゴシエーションの次元と呼びます。

+ +

Apache におけるネゴシエーション

+ +

リソースをネゴシエーションするためには、 + サーバは variant それぞれについての情報を知っておく必要があります。 + これは以下の二つの方法のどちらかで行われます。

+ + + +

type-map ファイルを使う

+ +

タイプマップは type-map ハンドラ + (もしくは、古い Apache + の設定と下位互換である mime タイプ + application/x-type-map) + に関連付けられたドキュメントです。 + この機能を使うためには、あるファイルの拡張子を + type-map + として定義するようなハンドラを、 + 設定ファイル中に置く必要があることに注意してください。 + これは

+
+  AddHandler type-map .var
+
+ をサーバ設定ファイル中に書くことが一番良い方法です。 + +

タイプマップファイルは記述するリソースと同じ名前を持っていて、 + 利用可能な variant それぞれのエントリを持っている必要があります。 + そして、このエントリは連続した HTTP のヘッダ行で構成されます。 + 異なる variant のためのエントリは空行で区切られています。 + エントリ中に空行が複数あってはいけません。 + 習慣的には、マップファイルは全体を結合したもののエントリから始まります + (しかしこれは必須ではなく、あったとしても無視されるものです)。 + 次に例を示します。このファイルはリソース foo + を記述しているので、foo.var という名前になります。

+
+  URI: foo
+
+  URI: foo.en.html
+  Content-type: text/html
+  Content-language: en
+
+  URI: foo.fr.de.html
+  Content-type: text/html;charset=iso-8859-2
+  Content-language: fr, de
+
+ たとえ MultiViews を使用するようになっていたとしても、 + ファイル名の拡張子よりタイプマップの方が優先権を持つということにも + 注意してください。 + variant の品質が違うときは、この画像のように (JPEG, GIF, ASCII + アートがあります) メディアタイプの "qs" + パラメータで指定されます。 +
+  URI: foo
+
+  URI: foo.jpeg
+  Content-type: image/jpeg; qs=0.8
+
+  URI: foo.gif
+  Content-type: image/gif; qs=0.5
+
+  URI: foo.txt
+  Content-type: text/plain; qs=0.01
+
+ +

qs 値の範囲は 0.000 から 1.000 です。qs 値が + 0.000 の variant は決して + 選択されないことに注意してください。'qs' 値のない variant + は qs 値 1.0 を 与えられます。qs + パラメータはクライアントの能力に関係無く、他の variant と + 比較したときの variant + の相対的な「品質」を示します。 + 例えば、写真を表現しようとしているときは JPEG + ファイルの方が普通は ASCII + ファイルよりも高い品質になります。しかし、リソースが元々 + ASCII アートで表現されているときは、ASCII ファイルの + 方が JPEG ファイルよりも高い品質になります。このように、qs + は 表現されるリソースの性質によって variant + 毎に特有の値を取ります。

+ +

認識されるヘッダの一覧は + mod_negotiation + ドキュメントにあります。

+ + +

Multiviews

+ +

MultiViews はディレクトリ毎のオプションで、 + <Directory>, <Location>, + <Files> や、(AllowOverride + が適切な値に 設定されていると) .htaccess + ファイルで Options + ディレクティブによって設定することができます。Options + AllMultiViews + をセットしないことに注意してください。明示的に + その名前を書く必要があります。

+ +

MultiViews の効果は以下のようになります: + サーバが /some/dir/foo + へのリクエストを受け取り、/some/dir で + MultiViews が有効であって、 + /some/dir/foo が存在しない場合、 + サーバはディレクトリを読んで foo.* + にあてはまる全てのファイルを探し、 + 事実上それらのファイルをマップするタイプマップを作ります。 + そのとき、メディアタイプとコンテントエンコーディングは、そのファイル名を + 直接指定したときと同じものが割り当てられます。 + それからクライアントの要求に一番合うものを選びます。

+ +

サーバがディレクトリの索引を作ろうとしていると、 + MultiViews + は DirectoryIndex + ディレクティブで指定されたファイルを探す過程にも + 適用されます。設定ファイルに

+
+  DirectoryIndex index
+
+ が書かれていて、index.html と + index.html3 が + 両方存在していると、サーバはその中から毎回どちらかを適当に選びます。 + もしその両方が存在せずに index.cgi + が存在していると、 サーバはそれを実行します。 + +

もしディレクトリを読んでいる際に、 + 文字セット、コンテントタイプ、言語、エンコーディングを + 指定するための mod_mime + で認識できる拡張子を持たないファイルが見つかると、結果は + MultiViewsMatch + ディレクティブの設定に依存します。このディレクティブは + ハンドラ、フィルタ、他のファイル拡張子タイプのどれが + MultiViews ネゴシエーションで使用できるかを決定します。

+ +

ネゴシエーション方法

+ Apache はリソースの variant の一覧を、タイプマップファイルか + ディレクトリ内のファイル名からかで取得した後、 + 「最適な」 variant を決定するために二つの方法の + どちらかを起動します。 + Apache のコンテントネゴシエーションの機能を使うために、 + どのようにしてこの調停が行われるか詳細を知る必要はありません。 + しかしながら、この文書の残りでは関心のある人のために、 + 使用されている方法について説明しています。 + +

ネゴシエーション方法は二つあります。

+ +
    +
  1. 通常は Apache のアルゴリズムを用いた Server + driven negotiation が使用されます。Apache + のアルゴリズムは後に詳細に説明されています。 + このアルゴリズムが使用された場合、Apache + はより良い結果になるように、特定の次元において品質の値を + 「変える」ことができます。Apache + が品質の値を変える方法は後で詳細に説明されています。
  2. + +
  3. RFC 2295 + で定義されている機構を用いてブラウザが特に指定した場合、 + transparent content negotiation + が使用されます。このネゴシエーション方法では、「最適な」 + variant の決定をブラウザが完全に制御することができます。 + ですから、結果はブラウザが使用しているアルゴリズムに依存します。 + Transparent negotiation の処理の過程で、ブラウザは RFC 2296 + で 定義されている 'remote variant selection algorithm' + を実行するように頼むことができます。
  4. +
+ +

ネゴシエーションの次元

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
次元説明
メディアタイプブラウザは Accept + ヘッダフィールドで優先傾向を指定します。 + アイテムそれぞれは、関連した品質数値を持つことができます。 + variant の説明も品質数値を持つことができます + ("qs" パラメータをご覧下さい)。
言語ブラウザは Accept-Language + ヘッダフィールドで優先傾向を指定します。 + 要素それぞれに品質数値を持たせることができます。 + variants は 0 か 1 つかそれ以上の言語と + 関連づけることができます。
エンコーディングブラウザは Accept-Encoding + ヘッダフィールドで優先傾向を指定します。 + 要素それぞれに品質数値を持たせることができます。
文字セットブラウザは Accept-Charset + ヘッダフィールドで優先傾向を指定します。 + 要素それぞれに品質数値を持たせることができます。 + variant はメディアタイプのパラメータとして文字セットを + 指定することもできます。
+ +

Apache ネゴシエーションアルゴリズム

+ +

ブラウザに返す「最適な」variant を (もしあれば) 選択するように + Apache は次のアルゴリズムを使うことができます。 + このアルゴリズムを設定により変更することはできません。 + 次のように動作します:

+ +
    +
  1. まずはじめに、ネゴシエーションの次元それぞれについて適切な + Accept* ヘッダフィールドを調べ、 + variant それぞれに品質を割り当てます。 + もしある次元の Accept* ヘッダでその variant + が許容できないことが示されていれば、それを削除します。 + variant が一つも残っていなければ、ステップ 4 に行きます。
  2. + +
  3. + 消去法で「最適な」 variant を選びます。 + 次のテストが順番に適用されます。 + テストで選択されなかった variant は削除されていきます。 + テスト後 variant が一つだけ残っていれば、それを最適なものとして + ステップ 3 に進みます。 + 複数 variant が残っていれば、次のテストに進みます。 + +
      +
    1. variant のメディアタイプの品質数値と Accept + ヘッダの品質数値との積を計算して、最高値の variant + を選びます。
    2. + +
    3. 言語品質数値が最高の variant を選びます。
    4. + +
    5. (もしあれば) Accept-Language ヘッダの言語順か、 + (もしあれば) LanguagePriority + ディレクティブの言語順で最適な言語の variant を選びます。
    6. + +
    7. 最高「レベル」のメディアパラメータ + (text/html メディアタイプのバージョンを与えるために使われます) + を持つ variant を選びます。
    8. + +
    9. Accept-Charset ヘッダ行で与えられている最高の文字セット + メディアパラメータを持つ variant を選びます。 + 明示的に除外されていない限り、ISO-8859-1 + が許容されるようになっています。 + text/* メディアタイプであるけれども + 特定の文字セットに明示的に関連づけられているわけではない + variant は ISO-8859-1 であると仮定されます。
    10. + +
    11. ISO-8859-1 ではない文字セットメディアパラメータと + 関連づけられている variant を選びます。 + そのような variant がない場合は、代わりに全ての + variant を選びます。
    12. + +
    13. 最適なエンコーディングの variant を選びます。 + もし user-agent が許容するエンコーディングがあれば、 + その variant のみを選びます。 + そうではなく、もしエンコードされたものとそうでない + variant が混ざって存在していたらエンコードされていない + variant のみを選びます。 + variant が全部エンコードされているか + variant が全部エンコードされていないという場合は、 + 全ての variant を選びます。
    14. + +
    15. 内容の最も短い variant を選びます。
    16. + +
    17. 残っている variant の最初のものを選びます。 + タイプマップファイルの最初にリストされているか、 + variant がディレクトリから最初に読み込まれる時に + ASCII順でソートしてファイル名が先頭になったか、のどちらかです。
    18. +
    +
  4. + +
  5. アルゴリズムを使って一つの「最適な」variant を選びましたので、 + それを応答として返します。ネゴシエーションの次元を指定するために + HTTP レスポンスヘッダ Vary が設定されます + (リソースのキャッシュをする時に、 + ブラウザやキャッシュはこの情報を使うことができます)。 + 以上で終わり。
  6. + +
  7. ここに来たということは、variant が一つも選択されなかった + (ブラウザが許容するものがなかったため) ということです。 + 406 ステータス ("No Acceptable representation" を意味する) + が、利用可能な variant のリストのついた HTML + ドキュメントとともに返されます。 + 相違の次元を示す HTTP Vary ヘッダも設定されます。
  8. +
+ +

品質の値を変える

+ + +

上記の Apaceh ネゴシエーションアルゴリズムの厳格な解釈で + 得られるであろう値から、Apache は品質数値を時々変えます。 + これは、このアルゴリズムで完全ではない、あるいは正確でない情報を送る + ブラウザ向けによりよい結果を得るために行われます。 + かなりポピュラーなブラウザで、もしないと間違った variant + を選択する結果になってしまうような Accept + ヘッダ情報を送るものもあります。 + ブラウザが完全で正しい情報を送っていれば、 + この数値変化は適用されません。

+ +

メディアタイプとワイルドカード

+ +

Accept: リクエストヘッダはメディアタイプの優先傾向を指定します。 + これはまた、"image/*" や "*/*" + といった「ワイルドカード」メディアタイプを含むことができます。 + ここで * は任意の文字列にマッチします。 + ですから、次の:

+
+  Accept: image/*, */*
+
+ を含むリクエストは、"image/" ではじまるタイプ全てが許容できる、 + そして他のどんなタイプも許容できる + (この場合はじめの "image/*" は冗長になります) + ことを示します。 + 扱うことのできる明示的なタイプに加えて、機械的に + ワイルドカードを送るブラウザもあります。例えば: +
+  Accept: text/html, text/plain, image/gif, image/jpeg, */*
+
+ こうすることの狙いは、明示的にリストしているタイプが優先されるけれども、 + 異なる表現が利用可能であればそれでも良い、ということです。 + しかしながら、上の基本的なアルゴリズムでは、 + */* ワイルドカードは他の全てのタイプと全く同等なので優先されません。 + ブラウザは */* にもっと低い品質 (優先) + 値を付けてリクエストを送るべきなのです。例えば: +
+  Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01
+
+ 明示的なタイプには品質数値が付けられていませんので、 + デフォルトの 1.0 (最高値) の優先になります。 + ワイルドカード */* は低い優先度 0.01 を与えられているので、 + 明示的にリストされているタイプに合致する variant がない場合にのみ、 + 他のタイプが返されます。 + +

もし Accept: ヘッダが q 値を全く含んでいなければ、 + 望みの挙動をするために、 + Apache は "*/*" があれば 0.01 の q 値を設定します。 + また、"type/*" の形のワイルドカードには 0.02 の q 値を設定します + (ですからこれらは "*/*" のマッチよりも優先されます)。 + もし Accept: ヘッダ中のメディアタイプのどれかが q + 値を含んでいれば、これらの特殊な値は適応されず、 + 正しい情報を送るブラウザからのリクエストは期待通りに + 動作するようになります。

+ +

言語ネゴシエーションの例外処理

+ +

Apache 2.0 では新たに、言語ネゴシエーションが適合するものを + 見つけるのに失敗した時に、優雅にフォールバックできるような + ネゴシエーションアルゴリズムが幾つか追加されました。

+ +

サーバのページをクライアントがリクエストしたけれども、 + ブラウザの送ってきた Accept-Language に合致するページが一つも + 見つからなかった場合に、サーバは "No Acceptable Variant" + か "Multiple Choices" レスポンスをクライアントに返します。 + これらのエラーメッセージを返さないように、 + このような場合には Apache が Accept-Language を無視して、 + クライアントのリクエストに明示的には合致しないドキュメントを + 提供するように設定できます。 + ForceLanguagePriority + ディレクティブは、これらのエラーの一つか両方をオーバーライドするために + 使用できて、 + LanguagePriority + ディレクティブの内容を使ってサーバの判断を代行するようにできます。

+ +

サーバは他に適合するものが見つからなければ、 + 言語サブセットで適合するものを試そうともします。 + 例えばクライアントが英国英語である en-GB 言語で + ドキュメントをリクエストした場合、サーバは HTTP/1.1 + 規格では、単に en とマークされているドキュメントを + マッチするものとすることは通常は許されていません。 + (英国英語は理解できるけど一般的な英語は理解できないという読み手は + 考えられないので、Accept-Language ヘッダで en-GB + を含んで en を含まないのはほぼ確実に設定の間違いである、 + ということに注意してください。 + ですが不幸なことに、多くのクライアントではデフォルトで + このような設定になっています。) + しかしながら、他の言語にはマッチせず、"No Acceptable Variants" + エラーを返したり、 LanguagePriority にフォールバック + しようとしているときは、 + サブセット指定を無視して、en-GBen + にマッチします。 + Apache はクライアントの許容言語リストに暗黙に + 非常に低い品質値の親言語を加えることになります。 + しかし、クライアントが "en-GB; qs=0.9, fr; qs=0.8" とリクエストして、 + サーバが "en" と "fr" と設計されたドキュメントを持っている場合は、 + "fr" ドキュメントが返されることに注意してください。 + このような処理は、HTTP 1.1 規格との整合性を維持して、 + 適切に設定されたクライアントともきちんと動作するために + 必要です。

+ + +

Transparent Content Negotiation の拡張

+ Apache は transparent content negotiation プロトコル + (RFC 2295) を次のように拡張しています。 + 特定のコンテントエンコーディングのみが利用可能である variant + に印を付けるために、新たに {encoding ..} + 要素を variant リスト中に使っています。 + リスト中のエンコードされた variant を認識し、 + Accept-Encoding リクエストヘッダに従って許容される + エンコードをもった variant は、どれでも候補 variant + として使用するように、 + RVSA/1.0 アルゴリズム (RFC 2296) の実装が拡張されました。 + RVSA/1.0 の実装では、最適な variant が見つかるまで、 + 計算した品質数値は小数点以下 5 桁まで丸めません。 + +

リンクと名前の変換に関する注意点

+ +

言語ネゴシエーションを使っている場合は、 + ファイルが一つ以上の拡張子を持てて、 + 拡張子の順番は通常は考慮されない + (詳細は mod_mime + を参照) ので、 + 幾つかの異なる名前の変換を選べることになります。

+ +

典型的なファイルでは、MIME タイプ拡張子 (例えば + html) を持っていて、エンコーディング拡張子 + (例えば gz) を持っているかもしれなくて、 + このファイルに異なる言語 variant を用意していれば、 + もちろん言語拡張子 (例えば en) + を持っているでしょう。

+ +

例:

+ + + +

ファイル名と、それに対して使えるリンクと使えないリンクの例です:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ファイル名使えるリンク使えないリンク
foo.html.enfoo
+ foo.html
-
foo.en.htmlfoofoo.html
foo.html.en.gzfoo
+ foo.html
foo.gz
+ foo.html.gz
foo.en.html.gzfoofoo.html
+ foo.html.gz
+ foo.gz
foo.gz.html.enfoo
+ foo.gz
+ foo.gz.html
foo.html
foo.html.gz.enfoo
+ foo.html
+ foo.html.gz
foo.gz
+ +

上の表を見て、拡張子なしのリンク (例えば foo) + がいつでも使えることに気が付くでしょう。 + この利点は、ドキュメントとして応答するファイルの + 実際のファイルタイプを隠蔽して、リンクの参照を変更することなく + 後からファイルを変更できる、 + 例えば html から shtml + に、あるいは cgi に変更できる点です。

+ +

リンクに MIME タイプを使い続けたい (例えば + foo.html)時は、言語拡張子は + (エンコーディング拡張子もあればそれも含めて) + MIME タイプ拡張子の右側になければなりません + (例えば foo.html.en)。

+ +

キャッシュに関する注意事項

+ +

キャッシュが一つの表現を保存しているときは、 + リクエスト URL と関連づけられています。 + 次にその URL がリクエストされた時に、キャッシュは + 保存されている表現を使用できます。しかし、 + リソースがサーバでネゴシエーション可能であれば、 + 最初のリクエストでキャッシュされて続くキャッシュヒットでは + 間違った応答を返してしまうということになりかねません。 + これを防ぐために、Apache はコンテントネゴシエーションの + 後に返された応答全てに、HTTP/1.0 クライアントでは + キャッシュ不可能の印をつけます。 + また、ネゴシエーションされた応答のキャッシュを可能にする + HTTP/1.1 プロトコルの機能も Apache はサポートします。

+ +

HTTP/1.0 準拠のクライアントからのリクエストに対しては、 + (ブラウザであろうとキャッシュであろうと) + ネゴシエーションを受けた応答のキャッシュを許すために、 + CacheNegotiatedDocs ディレクティブを使用できます。 + このディレクティブは、サーバ設定ファイルやバーチャルホストに書くことができ、 + 引数をとりません。 + HTTP/1.1 クライアントからのリクエストには効力を持ちません。

+ +

追加情報

+ +

コンテントネゴシエーションに関する追加情報は、 + Alan J. Flavell さんのLanguage + Negotiation Notes をご覧下さい。ですが、 + Apache 2.0 での変更点を含むためには更新されていないかもしれない + ということに注意してください。

+ + + + + -- 2.40.0