content-negotiation.html.en

Apache_2.0.59-Openssl_0.9 配置tomcat. Apache_2.0.59-Openssl_0.9 配置tomcat.

    send the explicit information to start with work as expected.</p>


<h3><a name="exceptions" id="exceptions">Language Negotiation Exceptions</a></h3>

    <p>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.</p>

    <p>When a client requests a page on your server, but the server
    cannot find a single page that matches the
    <code>Accept-language</code> 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 <code>Accept-language</code> in these cases and provide a
    document that does not explicitly match the client's request.  The
    <code class="directive"><a href="./mod/mod_negotiation.html#forcelanguagepriority">ForceLanguagePriority</a></code>
    directive can be used to override one or both of these error
    messages and substitute the servers judgement in the form of the
    <code class="directive"><a href="./mod/mod_negotiation.html#languagepriority">LanguagePriority</a></code>
    directive.</p>

    <p>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 <code>en-GB</code> 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
    <code>en</code>.  (Note that it is almost surely a configuration
    error to include <code>en-GB</code> and not <code>en</code> in the
    <code>Accept-Language</code> 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 <code class="directive"><a href="./mod/mod_negotiation.html#languagepriority">LanguagePriority</a></code>, the server
    will ignore the subset specification and match <code>en-GB</code>
    against <code>en</code> 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; q=0.9, fr; q=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.</p>

    <p>In order to support advanced techniques (such as cookies or
    special URL-paths) to determine the user's preferred language,
    since Apache 2.0.47 <code class="module"><a href="./mod/mod_negotiation.html">mod_negotiation</a></code> recognizes
    the <a href="env.html">environment variable</a>
    <code>prefer-language</code>. If it exists and contains an
    appropriate language tag, <code class="module"><a href="./mod/mod_negotiation.html">mod_negotiation</a></code> will
    try to select a matching variant. If there's no such variant,
    the normal negotiation process applies.</p>

    <div class="example"><h3>Example</h3><p><code>
      SetEnvIf Cookie "language=en" prefer-language=en<br />
      SetEnvIf Cookie "language=fr" prefer-language=fr
   </code></p></div>

</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="extensions" id="extensions">Extensions to Transparent Content
Negotiation</a></h2> 

<p>Apache extends the transparent content negotiation protocol (RFC
2295) as follows. A new <code>{encoding ..}</code> 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 <code>Accept-Encoding</code> request
header. The RVSA/1.0 implementation does not round computed quality
factors to 5 decimal places before choosing the best variant.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="naming" id="naming">Note on hyperlinks and naming conventions</a></h2>

    <p>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 <a href="mod/mod_mime.html#multipleext">mod_mime</a> documentation
    for details).</p>

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

    <p>Examples:</p>

    <ul>
      <li>foo.en.html</li>

      <li>foo.html.en</li>

      <li>foo.en.html.gz</li>
    </ul>

    <p>Here some more examples of filenames together with valid and
    invalid hyperlinks:</p>

    <table class="bordered">
      
      <tr>
        <th>Filename</th>

        <th>Valid hyperlink</th>

        <th>Invalid hyperlink</th>
      </tr>

      <tr>
        <td><em>foo.html.en</em></td>

        <td>foo<br />
         foo.html</td>

        <td>-</td>
      </tr>

      <tr>
        <td><em>foo.en.html</em></td>

        <td>foo</td>

        <td>foo.html</td>
      </tr>

      <tr>
        <td><em>foo.html.en.gz</em></td>

        <td>foo<br />
         foo.html</td>

        <td>foo.gz<br />
         foo.html.gz</td>
      </tr>

      <tr>
        <td><em>foo.en.html.gz</em></td>

        <td>foo</td>

        <td>foo.html<br />
         foo.html.gz<br />
         foo.gz</td>
      </tr>

      <tr>
        <td><em>foo.gz.html.en</em></td>

        <td>foo<br />
         foo.gz<br />
         foo.gz.html</td>

        <td>foo.html</td>
      </tr>

      <tr>
        <td><em>foo.html.gz.en</em></td>

        <td>foo<br />
         foo.html<br />
         foo.html.gz</td>

        <td>foo.gz</td>
      </tr>
    </table>

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

    <p>If you want to continue to use a MIME-type in your
    hyperlinks (<em>e.g.</em> <code>foo.html</code>) the language
    extension (including an encoding extension if there is one)
    must be on the right hand side of the MIME-type extension
    (<em>e.g.</em>, <code>foo.html.en</code>).</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="caching" id="caching">Note on Caching</a></h2>

    <p>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.</p>

    <p>For requests which come from a HTTP/1.0 compliant client
    (either a browser or a cache), the directive <code class="directive"><a href="./mod/mod_negotiation.html#cachenegotiateddocs">CacheNegotiatedDocs</a></code> 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.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="more" id="more">More Information</a></h2>

    <p>For more information about content negotiation, see Alan
    J. Flavell's <a href="http://ppewww.ph.gla.ac.uk/~flavell/www/lang-neg.html">Language
    Negotiation Notes</a>.  But note that this document may not be
    updated to include changes in Apache 2.0.</p>
</div></div>
<div class="bottomlang">
<p><span>Available Languages: </span><a href="./en/content-negotiation.html" title="English">&nbsp;en&nbsp;</a> |
<a href="./fr/content-negotiation.html" hreflang="fr" rel="alternate" title="Fran鏰is">&nbsp;fr&nbsp;</a> |
<a href="./ja/content-negotiation.html" hreflang="ja" rel="alternate" title="Japanese">&nbsp;ja&nbsp;</a> |
<a href="./ko/content-negotiation.html" hreflang="ko" rel="alternate" title="Korean">&nbsp;ko&nbsp;</a></p>
</div><div id="footer">
<p class="apache">Copyright 2006 The Apache Software Foundation.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
<p class="menu"><a href="./mod/">Modules</a> | <a href="./mod/directives.html">Directives</a> | <a href="./faq/">FAQ</a> | <a href="./glossary.html">Glossary</a> | <a href="./sitemap.html">Sitemap</a></p></div>
</body></html>