1 <?xml version="1.0" encoding="UTF-8" ?>
2 <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
3 <?xml-stylesheet type="text/xsl" href="./style/manual.ja.xsl"?>
4 <!-- English Revision: 675610:1029134 (outdated) -->
7 Licensed to the Apache Software Foundation (ASF) under one or more
8 contributor license agreements. See the NOTICE file distributed with
9 this work for additional information regarding copyright ownership.
10 The ASF licenses this file to You under the Apache License, Version 2.0
11 (the "License"); you may not use this file except in compliance with
12 the License. You may obtain a copy of the License at
14 http://www.apache.org/licenses/LICENSE-2.0
16 Unless required by applicable law or agreed to in writing, software
17 distributed under the License is distributed on an "AS IS" BASIS,
18 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
19 See the License for the specific language governing permissions and
20 limitations under the License.
23 <manualpage metafile="content-negotiation.xml.meta">
25 <title>コンテントネゴシエーション</title>
29 <p>Apache は HTTP/1.1 の規格に記述されているコンテントネゴシエーションを
32 言語、文字セット、エンコーディングの優先傾向に基づいて、
34 また、不完全なネゴシエーション情報を送ってくるブラウザからのリクエストを
35 もっと賢く取り扱えるよう、いくつか機能も実装してあります。</p>
38 <module>mod_negotiation</module>
39 モジュールによって提供されていて、デフォルトで組み込まれています。</p>
42 <section id="about"><title>コンテントネゴシエーションについて</title>
44 <p>リソースは、幾つか異なった表現で利用できる場合があります。
46 またはそれらの組み合わせで利用できるかも知れません。
47 もっとも適した選択をする方法の一つには、インデックスページを
48 ユーザに見せて、ユーザに選んでもらう方法があります。
49 しかし、サーバが自動的に選ぶことができる場合が多くあります。
51 どの表現を嗜好するかという情報を送ることで動作しています。
52 例えばブラウザは、可能ならフランス語で情報を見たい、
55 ブラウザはリクエストのヘッダで自分の優先傾向を知らせます。
56 フランス語のみの表現を要求する場合は、ブラウザは次を送ります。</p>
58 <example>Accept-Language: fr</example>
60 <p>この優先傾向は、選択可能な表現が存在して、
61 言語によって様々な表現がある場合にのみ適用される
64 <p>もっと複雑なリクエストの例を挙げましょう。
65 このブラウザはフランス語と英語を受け付ける、しかしフランス語を好む、
67 プレインテキストや他のタイプよりは HTML を好む、
68 他のメディアタイプよりは GIF や JPEG を好む、しかし最終手段として
69 他のメディアタイプも受け付ける、と設定されています。</p>
72 Accept-Language: fr; q=1.0, en; q=0.5<br />
73 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
76 <p>Apache は HTTP/1.1 規格で定義されている 'server
77 driven' コンテントネゴシエーションをサポートしています。
78 <code>Accept</code>, <code>Accept-Language</code>,
79 <code>Accept-Charset</code>, <code>Accept-Encoding</code>
80 リクエストヘッダを完全にサポートしています。Apache は
81 'transparent' コンテントネゴシエーションもサポートしていますが、
82 これは RFC 2295 と RFC 2296 で定義されている試験的な
84 これらの RFCで定義されている 'feature negotiation'
87 <p><strong>リソース</strong>とは URI
88 で特定される概念上のもののことです (RFC 2396)。 Apache
89 のような HTTP サーバは、その名前空間の中での
90 リソースの<strong>表現</strong>へのアクセスを提供します。
92 定義されたメディアタイプ、文字セット、エンコーディング等の
94 それぞれのリソースはある時点で 0 個、1 個、それ以上の表現と
95 関連付けられる可能性があります。複数の表現が利用できる場合は、
96 リソースは<strong>ネゴシエーション可能である</strong>とされ、
97 個々の表現は <strong>variant</strong> と呼ばれます。
98 ネゴシエーション可能なリソースの variant が異なる、
100 ネゴシエーションの<strong>次元</strong>と呼びます。</p>
103 <section id="negotiation"><title>Apache におけるネゴシエーション</title>
105 <p>リソースをネゴシエーションするためには、
106 サーバは variant それぞれについての情報を知っておく必要があります。
107 これは以下の二つの方法のどちらかで行われます。</p>
111 (<em>すなわち</em> <code>*.var</code> ファイル)
113 を明示的に挙げているファイルを指定します。</li>
116 を使って、サーバが暗黙の内にファイル名にパターン照合を
117 行なってその結果から選択する方法。</li>
120 <section id="type-map"><title>type-map ファイルを使う</title>
122 <p>タイプマップは <code>type-map</code> ハンドラ
124 の設定と下位互換である <glossary ref="mime-type">MIME タイプ</glossary>
125 <code>application/x-type-map</code>)
127 この機能を使うためには、あるファイルの拡張子を
128 <code>type-map</code>
130 設定ファイル中に置く必要があることに注意してください。
133 <example>AddHandler type-map .var</example>
135 <p>をサーバ設定ファイル中に書くことが一番良い方法です。</p>
137 <p>タイプマップファイルは記述するリソースと同じ名前を持っていて、
138 利用可能な variant それぞれのエントリを持っている必要があります。
139 そして、このエントリは連続した HTTP のヘッダ行で構成されます。
140 異なる variant のためのエントリは空行で区切られています。
141 エントリ中に空行が複数あってはいけません。
142 習慣的には、マップファイルは全体を結合したもののエントリから始まります
143 (しかしこれは必須ではなく、あったとしても無視されるものです)。
144 次に例を示します。このファイルはリソース <code>foo</code>
145 を記述しているので、<code>foo.var</code> という名前になります。</p>
150 URI: foo.en.html<br />
151 Content-type: text/html<br />
152 Content-language: en<br />
154 URI: foo.fr.de.html<br />
155 Content-type: text/html;charset=iso-8859-2<br />
156 Content-language: fr, de<br />
158 <p>たとえ MultiViews を使用するようになっていたとしても、
159 ファイル名の拡張子よりタイプマップの方が優先権を持つということにも
161 variant の品質が違うときは、この画像のように (JPEG, GIF, ASCII
162 アートがあります) メディアタイプの "qs"
169 Content-type: image/jpeg; qs=0.8<br />
172 Content-type: image/gif; qs=0.5<br />
175 Content-type: text/plain; qs=0.01<br />
178 <p>qs 値の範囲は 0.000 から 1.000 です。qs 値が
180 選択されないことに注意してください。'qs' 値のない variant
181 は qs 値 1.0 を 与えられます。qs
182 パラメータはクライアントの能力に関係無く、他の variant と
185 例えば、写真を表現しようとしているときは JPEG
187 ファイルよりも高い品質になります。しかし、リソースが元々
188 ASCII アートで表現されているときは、ASCII ファイルの
189 方が JPEG ファイルよりも高い品質になります。このように、qs
190 は 表現されるリソースの性質によって variant
194 <a href="mod/mod_negotiation.html#typemaps">mod_negotiation</a>
198 <section id="multiviews"><title>Multiviews</title>
200 <p><code>MultiViews</code> はディレクトリ毎のオプションで、
201 <code>httpd.conf</code>ファイルの
202 <directive module="core" type="section">Directory</directive>,
203 <directive module="core" type="section">Location</directive>,
204 <directive module="core" type="section">Files</directive>
205 セクション中や、(<directive module="core">AllowOverride</directive>
206 が適切な値に 設定されていると) <code>.htaccess</code>
207 ファイルで <directive module="core">Options</directive>
208 ディレクティブによって設定することができます。
209 <code>Options All</code> は
210 <code>MultiViews</code>
211 をセットしないことに注意してください。明示的に
214 <p><code>MultiViews</code> の効果は以下のようになります:
215 サーバが <code>/some/dir/foo</code>
216 へのリクエストを受け取り、<code>/some/dir</code> で
217 <code>MultiViews</code> が有効であって、
218 <code>/some/dir/foo</code> が存在<em>しない</em>場合、
219 サーバはディレクトリを読んで <code>foo.*</code>
221 事実上それらのファイルをマップするタイプマップを作ります。
222 そのとき、メディアタイプとコンテントエンコーディングは、そのファイル名を
223 直接指定したときと同じものが割り当てられます。
224 それからクライアントの要求に一番合うものを選びます。</p>
226 <p>サーバがディレクトリの索引を作ろうとしている場合、
227 <code>MultiViews</code>
228 は <directive module="mod_dir">DirectoryIndex</directive>
229 ディレクティブで指定されたファイルを探す過程にも
231 <example>DirectoryIndex index</example>
232 <p>が書かれていて、<code>index.html</code> と
233 <code>index.html3</code> が
234 両方存在していると、サーバはその中からどちらかを適当に選びます。
235 もしその両方が存在せずに <code>index.cgi</code>
236 が存在していると、 サーバはそれを実行します。</p>
239 文字セット、コンテントタイプ、言語、エンコーディングを
240 指定するための <code>mod_mime</code>
241 で認識できる拡張子を持たないファイルが見つかると、結果は
242 <directive module="mod_mime">MultiViewsMatch</directive>
243 ディレクティブの設定に依存します。このディレクティブは
244 ハンドラ、フィルタ、他のファイル拡張子タイプのどれが
245 MultiViews ネゴシエーションで使用できるかを決定します。</p>
249 <section id="methods"><title>ネゴシエーション方法</title>
251 <p>Apache はリソースの variant の一覧を、タイプマップファイルか
252 ディレクトリ内のファイル名からかで取得した後、
253 「最適な」 variant を決定するために二つの方法の
255 Apache のコンテントネゴシエーションの機能を使うために、
256 どのようにしてこの調停が行われるか詳細を知る必要はありません。
257 しかしながら、この文書の残りでは関心のある人のために、
258 使用されている方法について説明しています。</p>
260 <p>ネゴシエーション方法は二つあります。</p>
263 <li>通常は <strong>Apache のアルゴリズムを用いた Server
264 driven negotiation</strong> が使用されます。Apache
265 のアルゴリズムは後に詳細に説明されています。
266 このアルゴリズムが使用された場合、Apache
267 はより良い結果になるように、特定の次元において品質の値を
269 が品質の値を変える方法は後で詳細に説明されています。</li>
272 で定義されている機構を用いてブラウザが特に指定した場合、
273 <strong>transparent content negotiation</strong>
274 が使用されます。このネゴシエーション方法では、「最適な」
275 variant の決定をブラウザが完全に制御することができます。
276 ですから、結果はブラウザが使用しているアルゴリズムに依存します。
277 Transparent negotiation の処理の過程で、ブラウザは RFC 2296
278 で 定義されている 'remote variant selection algorithm'
279 を実行するように頼むことができます。</li>
282 <section id="dimensions"><title>ネゴシエーションの次元</title>
285 <columnspec><column width=".15"/><column width=".85"/></columnspec>
295 <td>ブラウザは <code>Accept</code>
297 アイテムそれぞれは、関連した品質数値を持つことができます。
298 variant の説明も品質数値を持つことができます
299 ("qs" パラメータをご覧下さい)。</td>
305 <td>ブラウザは <code>Accept-Language</code>
307 要素それぞれに品質数値を持たせることができます。
308 variants は 0 か 1 つかそれ以上の言語と
315 <td>ブラウザは <code>Accept-Encoding</code>
317 要素それぞれに品質数値を持たせることができます。</td>
323 <td>ブラウザは <code>Accept-Charset</code>
325 要素それぞれに品質数値を持たせることができます。
326 variant はメディアタイプのパラメータとして文字セットを
332 <section id="algorithm"><title>Apache ネゴシエーションアルゴリズム</title>
334 <p>ブラウザに返す「最適な」variant を (もしあれば) 選択するように
335 Apache は次のアルゴリズムを使うことができます。
336 このアルゴリズムを設定により変更することはできません。
340 <li>まずはじめに、ネゴシエーションの次元それぞれについて適切な
341 <em>Accept*</em> ヘッダフィールドを調べ、
342 variant それぞれに品質を割り当てます。
343 もしある次元の <em>Accept*</em> ヘッダでその variant
344 が許容できないことが示されていれば、それを削除します。
345 variant が一つも残っていなければ、ステップ 4 に行きます。</li>
348 消去法で「最適な」 variant を選びます。
350 テストで選択されなかった variant は削除されていきます。
351 テスト後 variant が一つだけ残っていれば、それを最適なものとして
353 複数 variant が残っていれば、次のテストに進みます。
356 <li>variant のメディアタイプの品質数値と <code>Accept</code>
357 ヘッダの品質数値との積を計算して、最高値の variant
360 <li>言語品質数値が最高の variant を選びます。</li>
362 <li>(もしあれば) <code>Accept-Language</code> ヘッダの言語順か、
364 <directive module="mod_negotiation">LanguagePriority</directive>
365 ディレクティブの言語順で最適な言語の variant を選びます。</li>
367 <li>最高「レベル」のメディアパラメータ
368 (text/html メディアタイプのバージョンを与えるために使われます)
369 を持つ variant を選びます。</li>
371 <li><code>Accept-Charset</code> ヘッダ行で与えられている最高の文字セット
372 メディアパラメータを持つ variant を選びます。
373 明示的に除外されていない限り、ISO-8859-1
375 <code>text/*</code> メディアタイプであるけれども
376 特定の文字セットに明示的に関連づけられているわけではない
377 variant は ISO-8859-1 であると仮定されます。</li>
379 <li>ISO-8859-1 <em>ではない</em>文字セットメディアパラメータと
380 関連づけられている variant を選びます。
381 そのような variant がない場合は、代わりに全ての
384 <li>最適なエンコーディングの variant を選びます。
385 もし user-agent が許容するエンコーディングがあれば、
387 そうではなく、もしエンコードされたものとそうでない
388 variant が混ざって存在していたらエンコードされていない
390 variant が全部エンコードされているか
391 variant が全部エンコードされていないという場合は、
392 全ての variant を選びます。</li>
394 <li>内容の最も短い variant を選びます。</li>
396 <li>残っている variant の最初のものを選びます。
397 タイプマップファイルの最初にリストされているか、
398 variant がディレクトリから最初に読み込まれる時に
399 ASCII順でソートしてファイル名が先頭になったか、のどちらかです。</li>
403 <li>アルゴリズムを使って一つの「最適な」variant を選びましたので、
404 それを応答として返します。ネゴシエーションの次元を指定するために
405 HTTP レスポンスヘッダ <code>Vary</code> が設定されます
407 ブラウザやキャッシュはこの情報を使うことができます)。
410 <li>ここに来たということは、variant が一つも選択されなかった
411 (ブラウザが許容するものがなかったため) ということです。
412 406 ステータス ("No Acceptable representation" を意味する)
413 が、利用可能な variant のリストのついた HTML
415 相違の次元を示す HTTP <code>Vary</code> ヘッダも設定されます。</li>
420 <section id="better"><title>品質の値を変える</title>
422 <p>上記の Apache ネゴシエーションアルゴリズムの厳格な解釈で
423 得られるであろう値から、Apache は品質数値を時々変えます。
424 これは、このアルゴリズムで完全ではない、あるいは正確でない情報を送る
425 ブラウザ向けによりよい結果を得るために行われます。
426 かなりポピュラーなブラウザで、もしないと間違った variant
427 を選択する結果になってしまうような <code>Accept</code>
429 ブラウザが完全で正しい情報を送っていれば、
432 <section id="wildcards"><title>メディアタイプとワイルドカード</title>
434 <p><code>Accept:</code> リクエストヘッダはメディアタイプの優先傾向を指定します。
435 これはまた、"image/*" や "*/*"
436 といった「ワイルドカード」メディアタイプを含むことができます。
437 ここで * は任意の文字列にマッチします。
440 <example>Accept: image/*, */*</example>
442 <p>を含むリクエストは、"image/" ではじまるタイプ全てが許容できる、
444 (この場合はじめの "image/*" は冗長になります)
446 扱うことのできる明示的なタイプに加えて、機械的に
447 ワイルドカードを送るブラウザもあります。例えば:</p>
450 Accept: text/html, text/plain, image/gif, image/jpeg, */*
452 <p>こうすることの狙いは、明示的にリストしているタイプが優先されるけれども、
453 異なる表現が利用可能であればそれでも良い、ということです。
454 しかしながら、上の基本的なアルゴリズムでは、
455 */* ワイルドカードは他の全てのタイプと全く同等なので優先されません。
456 ブラウザは */* にもっと低い品質 (優先)
457 値を付けてリクエストを送るべきなのです。例えば:</p>
459 Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01
461 <p>明示的なタイプには品質数値が付けられていませんので、
462 デフォルトの 1.0 (最高値) の優先になります。
463 ワイルドカード */* は低い優先度 0.01 を与えられているので、
464 明示的にリストされているタイプに合致する variant がない場合にのみ、
467 <p>もし <code>Accept:</code> ヘッダが q 値を全く含んで<em>いなければ</em>、
469 Apache は "*/*" があれば 0.01 の q 値を設定します。
470 また、"type/*" の形のワイルドカードには 0.02 の q 値を設定します
471 (ですからこれらは "*/*" のマッチよりも優先されます)。
472 もし <code>Accept:</code> ヘッダ中のメディアタイプのどれかが q
473 値を含んでいれば、これらの特殊な値は適応<em>されず</em>、
474 正しい情報を送るブラウザからのリクエストは期待通りに
478 <section id="exceptions"><title>言語ネゴシエーションの例外処理</title>
480 <p>Apache 2.0 では新たに、言語ネゴシエーションが適合するものを
481 見つけるのに失敗した時に、優雅にフォールバックできるような
482 ネゴシエーションアルゴリズムが幾つか追加されました。</p>
484 <p>サーバのページをクライアントがリクエストしたけれども、
485 ブラウザの送ってきた <code>Accept-Language</code> に合致するページが一つも
486 見つからなかった場合に、サーバは "No Acceptable Variant"
487 か "Multiple Choices" レスポンスをクライアントに返します。
488 これらのエラーメッセージを返さないように、
489 このような場合には Apache が <code>Accept-Language</code> を無視して、
490 クライアントのリクエストに明示的には合致しないドキュメントを
492 <directive module="mod_negotiation">ForceLanguagePriority</directive>
493 ディレクティブは、これらのエラーの一つか両方をオーバーライドするために
495 <directive module="mod_negotiation">LanguagePriority</directive>
496 ディレクティブの内容を使ってサーバの判断を代行するようにできます。</p>
498 <p>サーバは他に適合するものが見つからなければ、
499 言語サブセットで適合するものを試そうともします。
500 例えばクライアントが英国英語である <code>en-GB</code> 言語で
501 ドキュメントをリクエストした場合、サーバは HTTP/1.1
502 規格では、単に <code>en</code> とマークされているドキュメントを
503 マッチするものとすることは通常は許されていません。
504 (英国英語は理解できるけど一般的な英語は理解できないという読み手は
505 考えられないので、Accept-Language ヘッダで <code>en-GB</code>
506 を含んで <code>en</code> を含まないのはほぼ確実に設定の間違いである、
508 ですが不幸なことに、多くのクライアントではデフォルトで
510 しかしながら、他の言語にはマッチせず、"No Acceptable Variants"
512 <directive module="mod_negotiation">LanguagePriority</directive>
514 サブセット指定を無視して、<code>en-GB</code> を <code>en</code>
516 Apache はクライアントの許容言語リストに暗黙に
517 非常に低い品質値の親言語を加えることになります。
518 しかし、クライアントが "en-GB; q=0.9, fr; q=0.8" とリクエストして、
519 サーバが "en" と "fr" と設計されたドキュメントを持っている場合は、
520 "fr" ドキュメントが返されることに注意してください。
521 このような処理は、HTTP 1.1 規格との整合性を維持して、
522 適切に設定されたクライアントともきちんと動作するために
525 <p>より高度なテクニック (Cookie や特殊な URL パス等)
526 においてもユーザの言語選択をサポートするため、
527 Apache 2.0.47 からは、<module>mod_negotiation</module>
528 が<a href="env.html">環境変数</a> <code>prefer-language</code>
530 この変数が存在して、適切な言語タグが代入されているのであれば、
531 <module>mod_negotiation</module> は合致する variant
532 を選択しようとします。合致するものが無ければ、
533 通常のネゴシエーション手順が適用されます。</p>
535 <example><title>Example</title>
536 SetEnvIf Cookie "language=(.+)" prefer-language=$1<br />
537 Header append Vary cookie
542 <section id="extensions"><title>Transparent Content Negotiation
545 <p>Apache は transparent content negotiation プロトコル
546 (RFC 2295) を次のように拡張しています。
547 特定のコンテントエンコーディングのみが利用可能である variant
548 に印を付けるために、新たに <code>{encoding ..}</code>
549 要素を variant リスト中に使っています。
550 リスト中のエンコードされた variant を認識し、
551 <code>Accept-Encoding</code> リクエストヘッダに従って許容される
552 エンコードをもった variant は、どれでも候補 variant
554 RVSA/1.0 アルゴリズム (RFC 2296) の実装が拡張されました。
555 RVSA/1.0 の実装では、最適な variant が見つかるまで、
556 計算した品質数値は小数点以下 5 桁まで丸めません。</p>
559 <section id="naming"><title>リンクと名前の変換に関する注意点</title>
561 <p>言語ネゴシエーションを使っている場合は、
564 (詳細は <a href="mod/mod_mime.html#multipleext">mod_mime</a>
566 幾つかの異なる名前の変換を選べることになります。</p>
568 <p>典型的なファイルでは、MIME タイプ拡張子 (<em>例えば</em>
569 <code>html</code>) を持っていて、エンコーディング拡張子
570 (<em>例えば</em> <code>gz</code>) を持っているかもしれなくて、
571 このファイルに異なる言語 variant を用意していれば、
572 もちろん言語拡張子 (<em>例えば</em> <code>en</code>)
582 <li>foo.en.html.gz</li>
585 <p>ファイル名と、それに対して使えるリンクと使えないリンクの例です:</p>
587 <table border="1" cellpadding="8" cellspacing="0">
588 <columnspec><column width=".2"/><column width=".2"/>
589 <column width=".2"/></columnspec>
599 <td><em>foo.html.en</em></td>
608 <td><em>foo.en.html</em></td>
616 <td><em>foo.html.en.gz</em></td>
626 <td><em>foo.en.html.gz</em></td>
636 <td><em>foo.gz.html.en</em></td>
646 <td><em>foo.html.gz.en</em></td>
656 <p>上の表を見て、拡張子なしのリンク (<em>例えば</em> <code>foo</code>)
658 この利点は、ドキュメントとして応答するファイルの
659 実際のファイルタイプを隠蔽して、リンクの参照を変更することなく
661 <em>例えば</em> <code>html</code> から <code>shtml</code>
662 に、あるいは <code>cgi</code> に変更できる点です。</p>
664 <p>リンクに MIME タイプを使い続けたい (<em>例えば</em>
665 <code>foo.html</code>)時は、言語拡張子は
666 (エンコーディング拡張子もあればそれも含めて)
667 MIME タイプ拡張子の右側になければなりません
668 (<em>例えば</em> <code>foo.html.en</code>)。</p>
671 <section id="caching"><title>キャッシュに関する注意事項</title>
673 <p>キャッシュが一つの表現を保存しているときは、
674 リクエスト URL と関連づけられています。
675 次にその URL がリクエストされた時に、キャッシュは
676 保存されている表現を使用できます。しかし、
677 リソースがサーバでネゴシエーション可能であれば、
678 最初のリクエストでキャッシュされて続くキャッシュヒットでは
679 間違った応答を返してしまうということになりかねません。
680 これを防ぐために、Apache はコンテントネゴシエーションの
681 後に返された応答全てに、HTTP/1.0 クライアントでは
683 また、ネゴシエーションされた応答のキャッシュを可能にする
684 HTTP/1.1 プロトコルの機能も Apache はサポートします。</p>
686 <p>HTTP/1.0 準拠のクライアントからのリクエストに対しては、
687 (ブラウザであろうとキャッシュであろうと)
688 ネゴシエーションを受けた応答のキャッシュを許すために、
689 <directive module="mod_negotiation">CacheNegotiatedDocs</directive>
691 このディレクティブは、サーバ設定ファイルやバーチャルホストに書くことができ、
693 HTTP/1.1 クライアントからのリクエストには効力を持ちません。</p>
695 <p>HTTP/1.1 クライアントに対しては、レスポンスのネゴシエーション次元
696 を示すために <code>Vary</code> HTTP レスポンスヘッダを送ります。
697 キャッシュは、これを使って後続のリクエストに対してローカルコピーで応答できるか
699 ネゴシエーション次元とは関係なしにローカルコピーの使用を優先するようにするには、
700 <code>force-no-vary</code> <a href="env.html#special">環境変数</a>を