content-negotiation.html.en

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

    <p>If one of the files found when reading the directory does not
    have an extension recognized by <code>mod_mime</code> to designate
    its Charset, Content-Type, Language, or Encoding, then the result
    depends on the setting of the <code class="directive"><a href="./mod/mod_mime.html#multiviewsmatch">MultiViewsMatch</a></code> directive.  This
    directive determines whether handlers, filters, and other
    extension types can participate in MultiViews negotiation.</p>

</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="methods" id="methods">The Negotiation Methods</a></h2>

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

    <p>There are two negotiation methods:</p>

    <ol>
      <li><strong>Server driven negotiation with the Apache
      algorithm</strong> 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.</li>

      <li><strong>Transparent content negotiation</strong> 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.</li>
    </ol>

<h3><a name="dimensions" id="dimensions">Dimensions of Negotiation</a></h3>

    <table>
      
      <tr valign="top">
        <th>Dimension</th>

        <th>Notes</th>
      </tr>

      <tr valign="top">
        <td>Media Type</td>

        <td>Browser indicates preferences with the <code>Accept</code>
        header field. Each item can have an associated quality factor.
        Variant description can also have a quality factor (the "qs"
        parameter).</td>
      </tr>

      <tr valign="top">
        <td>Language</td>

        <td>Browser indicates preferences with the
        <code>Accept-Language</code> header field. Each item can have
        a quality factor. Variants can be associated with none, one or
        more than one language.</td>
      </tr>

      <tr valign="top">
        <td>Encoding</td>

        <td>Browser indicates preference with the
        <code>Accept-Encoding</code> header field. Each item can have
        a quality factor.</td>
      </tr>

      <tr valign="top">
        <td>Charset</td>

        <td>Browser indicates preference with the
        <code>Accept-Charset</code> header field. Each item can have a
        quality factor. Variants can indicate a charset as a parameter
        of the media type.</td>
      </tr>
    </table>


<h3><a name="algorithm" id="algorithm">Apache Negotiation Algorithm</a></h3>

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

    <ol>
      <li>First, for each dimension of the negotiation, check the
      appropriate <em>Accept*</em> header field and assign a
      quality to each variant. If the <em>Accept*</em> header for
      any dimension implies that this variant is not acceptable,
      eliminate it. If no variants remain, go to step 4.</li>

      <li>
        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. 

        <ol>
          <li>Multiply the quality factor from the <code>Accept</code>
          header with the quality-of-source factor for this variants
          media type, and select the variants with the highest
          value.</li>

          <li>Select the variants with the highest language quality
          factor.</li>

          <li>Select the variants with the best language match,
          using either the order of languages in the
          <code>Accept-Language</code> header (if present), or else
          the order of languages in the <code>LanguagePriority</code>
          directive (if present).</li>

          <li>Select the variants with the highest 'level' media
          parameter (used to give the version of text/html media
          types).</li>

          <li>Select variants with the best charset media
          parameters, as given on the <code>Accept-Charset</code>
          header line.  Charset ISO-8859-1 is acceptable unless
          explicitly excluded. Variants with a <code>text/*</code>
          media type but not explicitly associated with a particular
          charset are assumed to be in ISO-8859-1.</li>

          <li>Select those variants which have associated charset
          media parameters that are <em>not</em> ISO-8859-1. If
          there are no such variants, select all variants
          instead.</li>

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

          <li>Select the variants with the smallest content
          length.</li>

          <li>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.</li>
        </ol>
      </li>

      <li>The algorithm has now selected one 'best' variant, so
      return it as the response. The HTTP response header
      <code>Vary</code> is set to indicate the dimensions of
      negotiation (browsers and caches can use this information when
      caching the resource).  End.</li>

      <li>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 <code>Vary</code> header to
      indicate the dimensions of variance.</li>
    </ol>

</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="better" id="better">Fiddling with Quality
    Values</a></h2>

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

<h3><a name="wildcards" id="wildcards">Media Types and Wildcards</a></h3>

    <p>The <code>Accept:</code> 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:</p>

<div class="example"><p><code>Accept: image/*, */*</code></p></div>

    <p>would indicate that any type starting "image/" is acceptable,
    as is any other type.
    Some browsers routinely send wildcards in addition to explicit
    types they can handle. For example:</p>

<div class="example"><p><code>
  Accept: text/html, text/plain, image/gif, image/jpeg, */*
</code></p></div>
    <p>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.  Using explicit quality values,
    what the browser really wants is something like:</p>
<div class="example"><p><code>
  Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01
</code></p></div>
    <p>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.</p>

    <p>If the <code>Accept:</code> header contains <em>no</em> 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
    <code>Accept:</code> header contains a q factor, these special
    values are <em>not</em> applied, so requests from browsers which